From ntp-bounces@ietf.org Fri Sep 1 00:57:52 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EACD3133243; Fri, 1 Sep 2017 00:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504252672; bh=EiSKmFpWtYhPgkuItn7r2KvqCh7TKwlVCv8zdfyNMw0=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=VhhR7jugv3V8UaTpKGMRtDm5EAQ+Oy9y+jl7+s1LkGAjI9AST8PwPZUTqpfP1KO/I 4CeWgo0iwQf3se5h0EA/tj0fE0jYCI/nsyHbGVTgTQLePHWpyM3LMtl/DdiYENbevu v3ok6NMG4AcI4Ickx0zvBixLOYh6Ayo/fxba7ut4= 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 158B9132FFF; Fri, 1 Sep 2017 00:57:50 -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 o_FTWlnWDEIi; Fri, 1 Sep 2017 00:57:48 -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 612F8132FF4; Fri, 1 Sep 2017 00:57:48 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8ADE3C057FA1; Fri, 1 Sep 2017 07:57:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8ADE3C057FA1 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.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 2FF147E11A; Fri, 1 Sep 2017 07:57:45 +0000 (UTC) Date: Fri, 1 Sep 2017 09:57:57 +0200 From: Miroslav Lichvar To: dieter.sibold@ptb.de Message-ID: <20170901075757.GA6282@localhost> References: <20170831140258.GV11067@localhost> <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 01 Sep 2017 07:57:47 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , Daniel Franke , Karen O'Donoghue , "tictoc@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On Thu, Aug 31, 2017 at 10:36:34PM +0200, dieter.sibold@ptb.de wrote: > During the NTP interim meeting in Boston, Oct 2016 we had a thorough discussion of how to transport NTP's symmetric mode. At this time we had consensus to postpone the encapsulation of DTLS records within EF. Therefore, the draft represents the decisions take at that time. As Daniel pointed out. The current scheme to protect the symmetric mode has no disadvantage regarding time synchronization performance. I would guess that for the majority of mode 1/2 configuration it will work just well. It will certainly not work for the special configuration you mentioned. But an alternative approach can be specified, if future reveals that for any reason this is mandatory for the symmetric mode. But until that we should promote the current approach. If DTLS over NTP was just postponed, why specify now a different transport for this rarely used mode? Is anyone actually interested in implementing the symmetric mode over DTLS as it is proposed? If I understand it correctly, there is no plan to support it in any of the (few) existing open source implementations. Isn't there a rule about not specifying things for which there is no demand? Maybe I'm completely wrong, but to me it feels like there is a pressure for NTS to cover as many modes of NTP as quickly as possible. If we support two different transports, with every new change in NTP we will have to ask if and how it works in each of them. -- Miroslav Lichvar _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Fri Sep 1 00:57: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 158B9132FFF; Fri, 1 Sep 2017 00:57:50 -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 o_FTWlnWDEIi; Fri, 1 Sep 2017 00:57:48 -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 612F8132FF4; Fri, 1 Sep 2017 00:57:48 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8ADE3C057FA1; Fri, 1 Sep 2017 07:57:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8ADE3C057FA1 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.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 2FF147E11A; Fri, 1 Sep 2017 07:57:45 +0000 (UTC) Date: Fri, 1 Sep 2017 09:57:57 +0200 From: Miroslav Lichvar To: dieter.sibold@ptb.de Cc: "ntp@ietf.org" , Daniel Franke , Karen O'Donoghue , "tictoc@ietf.org" Message-ID: <20170901075757.GA6282@localhost> References: <20170831140258.GV11067@localhost> <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 01 Sep 2017 07:57:47 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 07:57:50 -0000 On Thu, Aug 31, 2017 at 10:36:34PM +0200, dieter.sibold@ptb.de wrote: > During the NTP interim meeting in Boston, Oct 2016 we had a thorough discussion of how to transport NTP's symmetric mode. At this time we had consensus to postpone the encapsulation of DTLS records within EF. Therefore, the draft represents the decisions take at that time. As Daniel pointed out. The current scheme to protect the symmetric mode has no disadvantage regarding time synchronization performance. I would guess that for the majority of mode 1/2 configuration it will work just well. It will certainly not work for the special configuration you mentioned. But an alternative approach can be specified, if future reveals that for any reason this is mandatory for the symmetric mode. But until that we should promote the current approach. If DTLS over NTP was just postponed, why specify now a different transport for this rarely used mode? Is anyone actually interested in implementing the symmetric mode over DTLS as it is proposed? If I understand it correctly, there is no plan to support it in any of the (few) existing open source implementations. Isn't there a rule about not specifying things for which there is no demand? Maybe I'm completely wrong, but to me it feels like there is a pressure for NTS to cover as many modes of NTP as quickly as possible. If we support two different transports, with every new change in NTP we will have to ask if and how it works in each of them. -- Miroslav Lichvar From ntp-bounces@ietf.org Fri Sep 1 01:11:15 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFB313312E; Fri, 1 Sep 2017 01:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504253475; bh=KM+O5MpVLuw64z3RB4pxVsfBkrgriCfZ7QRL37Ianeo=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=FPc0CQ4K2wCA/6Py2G/Nts5oP2WPlBhrfFa7EHMudW5rcY3uLM4gWJmbNYTyOQw31 wE0Iij7qr19urRZjCiPDoR7HdhtdoIwQatZHwHOsNoEkm3hQ51ZK4UHgudJXqHN4sF j+qC9JR6zrciJnmrGAnqPFCR5HqReQUA61lxw9Ng= 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 EDADF13304F for ; Fri, 1 Sep 2017 01:11:12 -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 LcQirfHRMNbk for ; Fri, 1 Sep 2017 01:11:11 -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 6E19C132F61 for ; Fri, 1 Sep 2017 01:11:11 -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 156B081DF5; Fri, 1 Sep 2017 08:11:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 156B081DF5 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.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 2A4B177E81; Fri, 1 Sep 2017 08:11:10 +0000 (UTC) Date: Fri, 1 Sep 2017 10:11:22 +0200 From: Miroslav Lichvar To: Daniel Franke Message-ID: <20170901081122.GX11067@localhost> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-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.25]); Fri, 01 Sep 2017 08:11:11 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , Sharon Goldberg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On Thu, Aug 31, 2017 at 08:27:46PM -0400, Daniel Franke wrote: > Miroslav, I just pushed a bunch of new detail in section 4 to git. Let > me know what you think of it and whether it affects your vote. I think it does clear up the issue with two active peers. Thanks. It doesn't change my vote, however. The following sentence might need to be expanded a bit further to prevent lasting DoS attacks on B. If, likely as a result of a configuration error, party A is configured as a symmetric active peer of party B, but party B is neither accepting DTLS handshakes from party A nor initiating one with it, then after a suitable number of failed attempts, party A MAY fall back to acting as an NTP client (mode 3) of party B using NTS-KE and NTS Extension Fields for NTPv4. If a MITM attacker prevents A from making a DTLS connection with B and it falls back to the client/server mode using NTS-KE, which is not blocked by the attacker, it should still be trying to make the DTLS connection. Maybe a better way to say this would be that party A MAY create a parallel client/server association with B using the NTS-KE. -- Miroslav Lichvar _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Fri Sep 1 01:11:16 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 EDADF13304F for ; Fri, 1 Sep 2017 01:11:12 -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 LcQirfHRMNbk for ; Fri, 1 Sep 2017 01:11:11 -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 6E19C132F61 for ; Fri, 1 Sep 2017 01:11:11 -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 156B081DF5; Fri, 1 Sep 2017 08:11:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 156B081DF5 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.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 2A4B177E81; Fri, 1 Sep 2017 08:11:10 +0000 (UTC) Date: Fri, 1 Sep 2017 10:11:22 +0200 From: Miroslav Lichvar To: Daniel Franke Cc: Sharon Goldberg , "ntp@ietf.org" Message-ID: <20170901081122.GX11067@localhost> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-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.25]); Fri, 01 Sep 2017 08:11:11 +0000 (UTC) Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 08:11:13 -0000 On Thu, Aug 31, 2017 at 08:27:46PM -0400, Daniel Franke wrote: > Miroslav, I just pushed a bunch of new detail in section 4 to git. Let > me know what you think of it and whether it affects your vote. I think it does clear up the issue with two active peers. Thanks. It doesn't change my vote, however. The following sentence might need to be expanded a bit further to prevent lasting DoS attacks on B. If, likely as a result of a configuration error, party A is configured as a symmetric active peer of party B, but party B is neither accepting DTLS handshakes from party A nor initiating one with it, then after a suitable number of failed attempts, party A MAY fall back to acting as an NTP client (mode 3) of party B using NTS-KE and NTS Extension Fields for NTPv4. If a MITM attacker prevents A from making a DTLS connection with B and it falls back to the client/server mode using NTS-KE, which is not blocked by the attacker, it should still be trying to make the DTLS connection. Maybe a better way to say this would be that party A MAY create a parallel client/server association with B using the NTS-KE. -- Miroslav Lichvar From ntp-bounces@ietf.org Fri Sep 1 02:03:26 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE1C133339; Fri, 1 Sep 2017 02:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504256606; bh=LWYDGUDuRzZ8Bs8ODk42l+n2WAw3JWA6X1rS4xG+uW4=; h=In-Reply-To:References:To:From:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=TUhpMJuI/j0o3gGsNoSmSKV5EmhYzBIw8+xSngXNESEH+/ivOD4BV+YZNQMKtldYw 3rbbkqpLnI4J67PcUaZ5nAKWgtgYpreNRlOX9fvuAqXtNbkZGqtyL6w+WuMgOeW6o9 o76ALXXFanOd8NAV48v1TnWJiU/q4/FybjDG4Aio= 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 967C813332B; Fri, 1 Sep 2017 02:03:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zAN-yg5hHZ9D; Fri, 1 Sep 2017 02:03:19 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AAB13320D; Fri, 1 Sep 2017 02:03:19 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v8193G8t023599-v8193G8v023599 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Sep 2017 11:03:16 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 5150458594B; Fri, 1 Sep 2017 11:03:15 +0200 (CEST) In-Reply-To: <20170831151837.535c0ee2@spidey.rellim.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> <20170831151837.535c0ee2@spidey.rellim.com> To: "Gary E. Miller" MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Fri, 1 Sep 2017 11:03:12 +0200 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , ntp , "tictoc@ietf.org" Content-Type: multipart/mixed; boundary="===============6530469683702281863==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" Dies ist eine mehrteilige Nachricht im MIME-Format. --===============6530469683702281863== Content-Type: multipart/alternative; boundary="=_alternative 0031BCB5C125818E_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0031BCB5C125818E_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable For the given application (comparison of performance of two different=20 techniques), I fail to see how that is supposed to work. Should running code be created for BOTH transport mechanisms (DTLS=20 encapsulation and regular NTP packet with authenticator token) before a=20 decision is made? I believe that is taking the "running code" maxim too far. Von: "Gary E. Miller" An:=20 Kopie: "ntp@ietf.org" , "tictoc@ietf.org" Datum: 01.09.2017 00:18 Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Gesendet von: "ntp" Yo Daniel! On Thu, 31 Aug 2017 08:34:02 -0400 Daniel Franke wrote: > Lots of people on this list seem to have the intuition that sending > time packets over DTLS can never be as accurate as sending them over > the NTP port with an authenticator attached. But as I showed in my > analysis the other day, that just ain't so. Analysis is great, but I'd like to see running code. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin [Anhang "attpwg8d.dat" gel=F6scht von Kristof Teichel/PTB]=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --=_alternative 0031BCB5C125818E_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable For the given application (comparison of performance of two different techniques), I fail to see how that is supposed to work.
Should running code be created for B= OTH transport mechanisms (DTLS encapsulation and regular NTP packet with authen= ticator token) before a decision is made?
I believe that is taking the "r= unning code" maxim too far.




Von:     &= nbsp;  "Gary E. Miller" <gem@rellim.com>
An:     &n= bsp;  
Kopie:    =    "ntp@ietf.org" <ntp@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Datum:    =    01.09.2017 00:18
Betreff:   &nbs= p;    Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
Gesendet von:  =      "ntp" <ntp-bounces@ietf.org>



Yo Daniel!

On Thu, 31 Aug 2017 08:34:02 -0400
Daniel Franke <dfoxfranke@gmail.com> wrote:

> Lots of people on this list seem to have the intuition that sending
> time packets over DTLS can never be as accurate as sending them over > the NTP port with an authenticator attached. But as I showed in my
> analysis the other day, that just ain't so.

Analysis is great, but I'd like to see running code.

RGDS
GARY
---------------------------------------------------------------------------=
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
                gem@rellim.com  Tel:+1 541 382 8588

                    Veritas liberabit vos. -- Quid est veritas?
   "If you can’t measure it, you can’t improve = it." - Lord Kelvin
[Anhang "attpwg8d.dat" gel=F6scht von Kristof Teichel/PTB] =5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--=_alternative 0031BCB5C125818E_=-- --===============6530469683702281863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============6530469683702281863==-- From nobody Fri Sep 1 02:03:31 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 967C813332B; Fri, 1 Sep 2017 02:03:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zAN-yg5hHZ9D; Fri, 1 Sep 2017 02:03:19 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AAB13320D; Fri, 1 Sep 2017 02:03:19 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v8193G8t023599-v8193G8v023599 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Sep 2017 11:03:16 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 5150458594B; Fri, 1 Sep 2017 11:03:15 +0200 (CEST) In-Reply-To: <20170831151837.535c0ee2@spidey.rellim.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> <20170831151837.535c0ee2@spidey.rellim.com> To: "Gary E. Miller" Cc: "ntp@ietf.org" , "ntp" , "tictoc@ietf.org" MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Fri, 1 Sep 2017 11:03:12 +0200 Content-Type: multipart/alternative; boundary="=_alternative 0031BCB5C125818E_=" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 09:03:23 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0031BCB5C125818E_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable For the given application (comparison of performance of two different=20 techniques), I fail to see how that is supposed to work. Should running code be created for BOTH transport mechanisms (DTLS=20 encapsulation and regular NTP packet with authenticator token) before a=20 decision is made? I believe that is taking the "running code" maxim too far. Von: "Gary E. Miller" An:=20 Kopie: "ntp@ietf.org" , "tictoc@ietf.org" Datum: 01.09.2017 00:18 Betreff: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Gesendet von: "ntp" Yo Daniel! On Thu, 31 Aug 2017 08:34:02 -0400 Daniel Franke wrote: > Lots of people on this list seem to have the intuition that sending > time packets over DTLS can never be as accurate as sending them over > the NTP port with an authenticator attached. But as I showed in my > analysis the other day, that just ain't so. Analysis is great, but I'd like to see running code. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can?t measure it, you can?t improve it." - Lord Kelvin [Anhang "attpwg8d.dat" gel=F6scht von Kristof Teichel/PTB]=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --=_alternative 0031BCB5C125818E_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable For the given application (comparison of performance of two different techniques), I fail to see how that is supposed to work.
Should running code be created for B= OTH transport mechanisms (DTLS encapsulation and regular NTP packet with authen= ticator token) before a decision is made?
I believe that is taking the "r= unning code" maxim too far.




Von:     &= nbsp;  "Gary E. Miller" <gem@rellim.com>
An:     &n= bsp;  
Kopie:    =    "ntp@ietf.org" <ntp@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Datum:    =    01.09.2017 00:18
Betreff:   &nbs= p;    Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
Gesendet von:  =      "ntp" <ntp-bounces@ietf.org>



Yo Daniel!

On Thu, 31 Aug 2017 08:34:02 -0400
Daniel Franke <dfoxfranke@gmail.com> wrote:

> Lots of people on this list seem to have the intuition that sending
> time packets over DTLS can never be as accurate as sending them over > the NTP port with an authenticator attached. But as I showed in my
> analysis the other day, that just ain't so.

Analysis is great, but I'd like to see running code.

RGDS
GARY
---------------------------------------------------------------------------=
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
                gem@rellim.com  Tel:+1 541 382 8588

                    Veritas liberabit vos. -- Quid est veritas?
   "If you can’t measure it, you can’t improve = it." - Lord Kelvin
[Anhang "attpwg8d.dat" gel=F6scht von Kristof Teichel/PTB] =5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

--=_alternative 0031BCB5C125818E_=-- From nobody Fri Sep 1 03:12:59 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 C3958133016 for ; Fri, 1 Sep 2017 03:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982] autolearn=no 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 D2qrtet03y7f for ; Fri, 1 Sep 2017 03:12:57 -0700 (PDT) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id E231B133009 for ; Fri, 1 Sep 2017 03:12:56 -0700 (PDT) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 8E05340605C; Fri, 1 Sep 2017 03:12:55 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: ntp@ietf.org cc: Hal Murray From: Hal Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Sep 2017 03:12:55 -0700 Message-Id: <20170901101255.8E05340605C@ip-64-139-1-69.sjc.megapath.net> Archived-At: Subject: [Ntp] TLS for NTS for NTP 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: Fri, 01 Sep 2017 10:12:58 -0000 I'm trying to understand the big picture. The typical protocol flow for client/server says the client uses TCP to do a TLS handshake. (It's about 1/3 of the way down on page 5 of draft 09.) How complicated is that? Remember that we have to do this without knowing the time. I assume most implementations will be using some TLS package. Can somebody give me a quick lesson in TLS? Is there a solid package that runs on most OSes? Is the API clean? Can it handle the time-not-known case? What else should I ask? ... That paragraph says "only one round trip". Is that after the TLS setup, or can it be piggybacked on TLS so that TLS+NTS is only one round trip? TLS needs certificates. Do we want to piggyback on the root certificates distributed with most OSes, or do we want the admin setting things up to provide certificates for the servers they select? How much would already having the right certificates simplify the TLS code? Is this going to work OK on IoT devices? How about spares that have been sitting on the shelf for a long time? -- These are my opinions. I hate spam. From ntp-bounces@ietf.org Fri Sep 1 03:12:59 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED521330C4; Fri, 1 Sep 2017 03:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504260779; bh=2KxQ7XdPGIK0IiGHimivB4kaH6JH9ZqYu3s/ApSMbLU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=AlhRCdKN/0WtstasL8VWVDnYZG/kWqFdbSBzEjDAkRnX34KTiHgbVCLyBzhNSzEto SzGtLg0yHOhbtnbBzn+6fKem7OS5RcrmVVqOiYYseLTd4c8ON7uY9UZnjxpXBhLDUn etCTssLSZBDcy3s337QABvbdc2/qTywTqU0FHtUs= 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 C3958133016 for ; Fri, 1 Sep 2017 03:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982] autolearn=no 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 D2qrtet03y7f for ; Fri, 1 Sep 2017 03:12:57 -0700 (PDT) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id E231B133009 for ; Fri, 1 Sep 2017 03:12:56 -0700 (PDT) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 8E05340605C; Fri, 1 Sep 2017 03:12:55 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: ntp@ietf.org From: Hal Murray Mime-Version: 1.0 Date: Fri, 01 Sep 2017 03:12:55 -0700 Message-Id: <20170901101255.8E05340605C@ip-64-139-1-69.sjc.megapath.net> Archived-At: Subject: [Ntp] TLS for NTS for NTP 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: , Cc: Hal Murray Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" I'm trying to understand the big picture. The typical protocol flow for client/server says the client uses TCP to do a TLS handshake. (It's about 1/3 of the way down on page 5 of draft 09.) How complicated is that? Remember that we have to do this without knowing the time. I assume most implementations will be using some TLS package. Can somebody give me a quick lesson in TLS? Is there a solid package that runs on most OSes? Is the API clean? Can it handle the time-not-known case? What else should I ask? ... That paragraph says "only one round trip". Is that after the TLS setup, or can it be piggybacked on TLS so that TLS+NTS is only one round trip? TLS needs certificates. Do we want to piggyback on the root certificates distributed with most OSes, or do we want the admin setting things up to provide certificates for the servers they select? How much would already having the right certificates simplify the TLS code? Is this going to work OK on IoT devices? How about spares that have been sitting on the shelf for a long time? -- These are my opinions. I hate spam. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Fri Sep 1 05:59:08 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B601133110; Fri, 1 Sep 2017 05:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504270748; bh=9ACTKho6po2BytVl0k7NS2d3yhk8zZLVrzl4+I75n3A=; h=To:References:From:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=U+9feRDWJMBUdnFotvVwpNq8RiH9lk8huuEzUtwMllXRsWt4SMo/xtv8UljbjZRjB zGEcTp484NRYfPon5knuhlI0h/Fu2Na+IuDO3tehCx22fADdgShFVdo7Mt85H1T5wZ 7+f2WZONNiX93T9JqZ15/ez7gCPQi/6EA7hSSzbw= 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 994E0132969 for ; Fri, 1 Sep 2017 05:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001] 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 CoNXHcaO7X1m for ; Fri, 1 Sep 2017 05:59:05 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CE21330FE for ; Fri, 1 Sep 2017 05:59:02 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D56FC880CC for ; Fri, 1 Sep 2017 05:59:02 -0700 (PDT) Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8EB143280AE4 for ; Fri, 1 Sep 2017 05:59:02 -0700 (PDT) To: ntp@ietf.org References: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> From: Brian Haberman Message-ID: Date: Fri, 1 Sep 2017 08:58:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> Archived-At: Subject: Re: [Ntp] Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 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: , Content-Type: multipart/mixed; boundary="===============3711452146146161604==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============3711452146146161604== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8FFhpSTdEB7rrkoPjq6Fk3OelGKg8wPKE" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8FFhpSTdEB7rrkoPjq6Fk3OelGKg8wPKE Content-Type: multipart/mixed; boundary="J73vPutk9Gm2Ic73Qv6KODUSXqaGjx12o"; protected-headers="v1" From: Brian Haberman To: ntp@ietf.org Message-ID: Subject: Re: [Ntp] Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 References: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> In-Reply-To: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> --J73vPutk9Gm2Ic73Qv6KODUSXqaGjx12o Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ulrich, Thanks for the review and comments! On 8/31/17 7:39 AM, Ulrich Windl wrote: > Hello! >=20 > I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 t= o verify my older implementation of NTP control messages. > I found some things that are strange! For example: >=20 > (Page 4): "The original development of the NTP daemon included a remote= facility (ntpdc) for monitoring and configuration. This facility used mo= de 7 commands to communicate with the NTP daemon. This document illustrat= es the mode 7 packet format only.": I thought the document describes mode= _6_ packets!? >=20 Someone asked that the mode 7 packet format be added to this document for completeness. The section you reference is strictly for mode 7. The previous section on that page (Section 1.1) discusses the mode 6 commands= =2E > Similar "The mode 7 message format is shown in Figure 3.: Why describe = the packet format then? >=20 See above. > While the draft talks about sequence and version numbers in the mode 7 = packet, it fails to specify it for mode 6 packets: > "Version Number (VN): This is a three-bit integer indicating a minimum = NTP version number. NTP servers do not respond to control messages with a= n unrecognized version number. Requests may intentionally use a lower ver= sion number to enable interoperability with earlier versions of NTP. Resp= onses carry the same version as the corresponding request.": What is the = version number the draft specifies? Obviously the first NTP version to su= pport a mode 6 or 7 packet is version 2. The minimum version would be 2. Given that there doesn't seem to be any interest in adding new mode 6 commands, I didn't see a need to specify a version number for this document. If it would help, I could indicate that this document specifies mode 6 commands for version 4 (and earlier).= > As the definition of the Clock (Radio) Status word is quite different b= etween NTPv3 and NTPv4 (just as the System Event Code is) I wonder how a = conforming implementation will handle the VN transmitted in the request p= acket: Will it respond with the correct packet regarding NV, will it flag= obsolete requests as an error (the current implementation does not), or = will it always return the current format? ("will" obviously should either= "SHOULD" or "MUST" in a specification) >=20 That is a good point for the WG to discuss. The goal of this document was to ensure a stable reference for mode 6 commands that were originally described in RFC 1305 (since obsoleted). My view is that it should return the format that matches the version number, but I do not maintain an NTP implementation, so this should be discussed. > On page 6: "Each request uses a different sequence number.": Is this a = recommendation (SHOULD) or a requirement (MUST)? Obviously it should help= against spurious packets being received (or for multiple outstanding req= uests when the order of packets received may vary). I think this needs to be a MUST statement. That particular text was lifted directly out of 1305 before the introduction of 2119 keywords. >=20 > An unanswered issue is how to find out what version the remote party su= pports, i.e. how to find out whether the remote party is NTPv3 or NTPv4 (= for example). Reading variable "version" with a low VN to guess the versi= on will fail on Solaris for example, where the daemon does not return a v= ersion string... To me, that is adding a new feature/command to mode 6 to perform version discovery. Is that necessary? Regards, Brian --J73vPutk9Gm2Ic73Qv6KODUSXqaGjx12o-- --8FFhpSTdEB7rrkoPjq6Fk3OelGKg8wPKE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZqVmVAAoJEBOZRqCi7goqWVgH/RuD8ODQKYPC9WsutIElHZyR 7ZKp6MTa/kwNiRjmXNCKhI/2T3ntQD8vspcKbuv/Mzhf3umkrGIbDDF9VdjzzeXW Va3BD3SYtxpunlgD9ViZIed7vS08Hm5hefS4sQ5+FSI1gsD0NdkGAffb2jUrmy5i nJfQoLeBmzvi7pvp1bbyDydSSvltoIia8w8dSWmprSMoEuWeAfrNbmpZ4uRkD6t/ XxNikcJ1ikddTcMcu9PtQBVQi/PDgSK2GC8S1XJEddWDLbdTSSMNVm2cnm9Iv+v+ 1BrEc5T+sVdjfpjZwDUs1oFPRBE1yFl1Lqzxuoj694Lv33XU6P8awluCj1NlC7U= =AKBR -----END PGP SIGNATURE----- --8FFhpSTdEB7rrkoPjq6Fk3OelGKg8wPKE-- --===============3711452146146161604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============3711452146146161604==-- From nobody Fri Sep 1 05:59:08 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 994E0132969 for ; Fri, 1 Sep 2017 05:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001] 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 CoNXHcaO7X1m for ; Fri, 1 Sep 2017 05:59:05 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CE21330FE for ; Fri, 1 Sep 2017 05:59:02 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D56FC880CC for ; Fri, 1 Sep 2017 05:59:02 -0700 (PDT) Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8EB143280AE4 for ; Fri, 1 Sep 2017 05:59:02 -0700 (PDT) To: ntp@ietf.org References: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> From: Brian Haberman Message-ID: Date: Fri, 1 Sep 2017 08:58:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8FFhpSTdEB7rrkoPjq6Fk3OelGKg8wPKE" Archived-At: Subject: Re: [Ntp] Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 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: Fri, 01 Sep 2017 12:59:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8FFhpSTdEB7rrkoPjq6Fk3OelGKg8wPKE Content-Type: multipart/mixed; boundary="J73vPutk9Gm2Ic73Qv6KODUSXqaGjx12o"; protected-headers="v1" From: Brian Haberman To: ntp@ietf.org Message-ID: Subject: Re: [Ntp] Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 References: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> In-Reply-To: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> --J73vPutk9Gm2Ic73Qv6KODUSXqaGjx12o Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ulrich, Thanks for the review and comments! On 8/31/17 7:39 AM, Ulrich Windl wrote: > Hello! >=20 > I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 t= o verify my older implementation of NTP control messages. > I found some things that are strange! For example: >=20 > (Page 4): "The original development of the NTP daemon included a remote= facility (ntpdc) for monitoring and configuration. This facility used mo= de 7 commands to communicate with the NTP daemon. This document illustrat= es the mode 7 packet format only.": I thought the document describes mode= _6_ packets!? >=20 Someone asked that the mode 7 packet format be added to this document for completeness. The section you reference is strictly for mode 7. The previous section on that page (Section 1.1) discusses the mode 6 commands= =2E > Similar "The mode 7 message format is shown in Figure 3.: Why describe = the packet format then? >=20 See above. > While the draft talks about sequence and version numbers in the mode 7 = packet, it fails to specify it for mode 6 packets: > "Version Number (VN): This is a three-bit integer indicating a minimum = NTP version number. NTP servers do not respond to control messages with a= n unrecognized version number. Requests may intentionally use a lower ver= sion number to enable interoperability with earlier versions of NTP. Resp= onses carry the same version as the corresponding request.": What is the = version number the draft specifies? Obviously the first NTP version to su= pport a mode 6 or 7 packet is version 2. The minimum version would be 2. Given that there doesn't seem to be any interest in adding new mode 6 commands, I didn't see a need to specify a version number for this document. If it would help, I could indicate that this document specifies mode 6 commands for version 4 (and earlier).= > As the definition of the Clock (Radio) Status word is quite different b= etween NTPv3 and NTPv4 (just as the System Event Code is) I wonder how a = conforming implementation will handle the VN transmitted in the request p= acket: Will it respond with the correct packet regarding NV, will it flag= obsolete requests as an error (the current implementation does not), or = will it always return the current format? ("will" obviously should either= "SHOULD" or "MUST" in a specification) >=20 That is a good point for the WG to discuss. The goal of this document was to ensure a stable reference for mode 6 commands that were originally described in RFC 1305 (since obsoleted). My view is that it should return the format that matches the version number, but I do not maintain an NTP implementation, so this should be discussed. > On page 6: "Each request uses a different sequence number.": Is this a = recommendation (SHOULD) or a requirement (MUST)? Obviously it should help= against spurious packets being received (or for multiple outstanding req= uests when the order of packets received may vary). I think this needs to be a MUST statement. That particular text was lifted directly out of 1305 before the introduction of 2119 keywords. >=20 > An unanswered issue is how to find out what version the remote party su= pports, i.e. how to find out whether the remote party is NTPv3 or NTPv4 (= for example). Reading variable "version" with a low VN to guess the versi= on will fail on Solaris for example, where the daemon does not return a v= ersion string... To me, that is adding a new feature/command to mode 6 to perform version discovery. Is that necessary? Regards, Brian --J73vPutk9Gm2Ic73Qv6KODUSXqaGjx12o-- --8FFhpSTdEB7rrkoPjq6Fk3OelGKg8wPKE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZqVmVAAoJEBOZRqCi7goqWVgH/RuD8ODQKYPC9WsutIElHZyR 7ZKp6MTa/kwNiRjmXNCKhI/2T3ntQD8vspcKbuv/Mzhf3umkrGIbDDF9VdjzzeXW Va3BD3SYtxpunlgD9ViZIed7vS08Hm5hefS4sQ5+FSI1gsD0NdkGAffb2jUrmy5i nJfQoLeBmzvi7pvp1bbyDydSSvltoIia8w8dSWmprSMoEuWeAfrNbmpZ4uRkD6t/ XxNikcJ1ikddTcMcu9PtQBVQi/PDgSK2GC8S1XJEddWDLbdTSSMNVm2cnm9Iv+v+ 1BrEc5T+sVdjfpjZwDUs1oFPRBE1yFl1Lqzxuoj694Lv33XU6P8awluCj1NlC7U= =AKBR -----END PGP SIGNATURE----- --8FFhpSTdEB7rrkoPjq6Fk3OelGKg8wPKE-- From ntp-bounces@ietf.org Fri Sep 1 06:56:29 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18106132E3C; Fri, 1 Sep 2017 06:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504274189; bh=UZKHZ050/C96jKnUNHzHXye5cWKXZfC8BRNs9Z29dB8=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=oW3acyvFKLY2EkhTJu4qTzWdc8s17qn0dNkaxINtUMxwEyQrPTBb0oJurMJtC+WPN K8j+q4yi12rk9MbueG6UNGK6uWlXu9MrA7537Vj2QtWFrR9sp2cWEK6F8RrDrE2PtJ imln+RGuDg+xapYHDMfsJrjIz4W90DCjFDY/eHvM= 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 6677B132396 for ; Fri, 1 Sep 2017 06:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Hqyf7tUILSpN for ; Fri, 1 Sep 2017 06:56:25 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8C713359E for ; Fri, 1 Sep 2017 06:56:21 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 63C2879585 for ; Fri, 1 Sep 2017 15:56:19 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 7B9E579581 for ; Fri, 1 Sep 2017 15:56:17 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Fri, 01 Sep 2017 15:56:17 +0200 Message-Id: <59A966FF020000A100027B46@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Fri, 01 Sep 2017 15:56:15 +0200 From: "Ulrich Windl" To: "ntp@ietf.org" , References: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: Re: Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" >>> Brian Haberman schrieb am 01.09.2017 um 14:58 in Nachricht : > Hi Ulrich, > Thanks for the review and comments! > > On 8/31/17 7:39 AM, Ulrich Windl wrote: >> Hello! >> >> I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 to > verify my older implementation of NTP control messages. >> I found some things that are strange! For example: >> >> (Page 4): "The original development of the NTP daemon included a remote > facility (ntpdc) for monitoring and configuration. This facility used mode 7 > commands to communicate with the NTP daemon. This document illustrates the > mode 7 packet format only.": I thought the document describes mode _6_ > packets!? >> > > Someone asked that the mode 7 packet format be added to this document > for completeness. The section you reference is strictly for mode 7. The > previous section on that page (Section 1.1) discusses the mode 6 commands. Yes, maybe move the description for that packet to some appendix. > >> Similar "The mode 7 message format is shown in Figure 3.: Why describe the > packet format then? >> > > See above. See above also ;-). > >> While the draft talks about sequence and version numbers in the mode 7 > packet, it fails to specify it for mode 6 packets: >> "Version Number (VN): This is a three-bit integer indicating a minimum NTP > version number. NTP servers do not respond to control messages with an > unrecognized version number. Requests may intentionally use a lower version > number to enable interoperability with earlier versions of NTP. Responses > carry the same version as the corresponding request.": What is the version > number the draft specifies? Obviously the first NTP version to support a mode > 6 or 7 packet is version 2. > > The minimum version would be 2. Given that there doesn't seem to be any > interest in adding new mode 6 commands, I didn't see a need to specify a > version number for this document. If it would help, I could indicate > that this document specifies mode 6 commands for version 4 (and earlier). As I indicated, the problem is not only the assigned command numbers (opcode), but also the interpretation of some status words: Maybe try to add a section on how to find out what status format the server being queried does send back. Maybe then you'll see my problem... ;-) > >> As the definition of the Clock (Radio) Status word is quite different > between NTPv3 and NTPv4 (just as the System Event Code is) I wonder how a > conforming implementation will handle the VN transmitted in the request > packet: Will it respond with the correct packet regarding NV, will it flag > obsolete requests as an error (the current implementation does not), or will > it always return the current format? ("will" obviously should either "SHOULD" > or "MUST" in a specification) >> > > That is a good point for the WG to discuss. The goal of this document > was to ensure a stable reference for mode 6 commands that were > originally described in RFC 1305 (since obsoleted). My view is that it > should return the format that matches the version number, but I do not > maintain an NTP implementation, so this should be discussed. Also the opcodes specified are more than those of RFC1305. > >> On page 6: "Each request uses a different sequence number.": Is this a > recommendation (SHOULD) or a requirement (MUST)? Obviously it should help > against spurious packets being received (or for multiple outstanding requests > when the order of packets received may vary). > > I think this needs to be a MUST statement. That particular text was > lifted directly out of 1305 before the introduction of 2119 keywords. > >> >> An unanswered issue is how to find out what version the remote party > supports, i.e. how to find out whether the remote party is NTPv3 or NTPv4 > (for example). Reading variable "version" with a low VN to guess the version > will fail on Solaris for example, where the daemon does not return a version > string... > > To me, that is adding a new feature/command to mode 6 to perform version > discovery. Is that necessary? I think yes, because the alternatives are ugly. Here are snipplets from some Perl code I wrote years ago: my $NTPv4 = $vars->has_variable('frequency'); # NTPv4 or newer? [...] # guess NTP version $control = NTP_Control->new($ht); if (my $vars = $control->read_vars(0, 'version')) { my $ver = $vars->variable('version') // ''; if ($ver =~ /^x?ntp[^\d]*(\d)(?:\.\d)/) { $ht->ntp_version($1); ::Log(0, 'D', $logger, "NTP version found to be", $ht->ntp_version(), "($ver)") if ($debug > 2); } else { ::Log(0, 'E', $logger, "Failed to parse version: $ver"); } } else { ::Log(0, 'E', $logger, 'Failed to query NTP version for', $ht->host_sock_string()); goto out; # no response, probably no NTP } And not to talk about the mess with variable names: if (!$NTPv4) { $vars->set_variable('frequency', $vars->variable('freq') / 1000); $vars->set_variable('offset', $vars->variable('phase')); $vars->set_variable('noise', $vars->variable('error')); $vars->set_variable('jitter', 0); $vars->set_variable('stability', '0'); } else { # ntpd 4.2.6p2 "introduces" "new" variables $vars->copy_variable('rootdispersion', 'rootdisp'); $vars->copy_variable('noise', 'clk_jitter'); $vars->copy_variable('jitter', 'sys_jitter'); $vars->copy_variable('stability', 'clk_wander'); $vars->copy_variable('poll', 'tc'); # ntpd 4.2.8 also has new variables # "clk_jitter" (CS_ERROR), Regards, Ulrich _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Fri Sep 1 06:56:29 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 6677B132396 for ; Fri, 1 Sep 2017 06:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Hqyf7tUILSpN for ; Fri, 1 Sep 2017 06:56:25 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8C713359E for ; Fri, 1 Sep 2017 06:56:21 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 63C2879585 for ; Fri, 1 Sep 2017 15:56:19 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 7B9E579581 for ; Fri, 1 Sep 2017 15:56:17 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Fri, 01 Sep 2017 15:56:17 +0200 Message-Id: <59A966FF020000A100027B46@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Fri, 01 Sep 2017 15:56:15 +0200 From: "Ulrich Windl" To: "ntp@ietf.org" , References: <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> <59A7F55B020000A100027B05@gwsmtp1.uni-regensburg.de> 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: Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 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: Fri, 01 Sep 2017 13:56:28 -0000 >>> Brian Haberman schrieb am 01.09.2017 um = 14:58 in Nachricht : > Hi Ulrich, > Thanks for the review and comments! >=20 > On 8/31/17 7:39 AM, Ulrich Windl wrote: >> Hello! >>=20 >> I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 = to=20 > verify my older implementation of NTP control messages. >> I found some things that are strange! For example: >>=20 >> (Page 4): "The original development of the NTP daemon included a = remote=20 > facility (ntpdc) for monitoring and configuration. This facility used = mode 7=20 > commands to communicate with the NTP daemon. This document illustrates = the=20 > mode 7 packet format only.": I thought the document describes mode = _6_=20 > packets!? >>=20 >=20 > Someone asked that the mode 7 packet format be added to this document > for completeness. The section you reference is strictly for mode 7. The > previous section on that page (Section 1.1) discusses the mode 6 = commands. Yes, maybe move the description for that packet to some appendix. >=20 >> Similar "The mode 7 message format is shown in Figure 3.: Why describe = the=20 > packet format then? >>=20 >=20 > See above. See above also ;-). >=20 >> While the draft talks about sequence and version numbers in the mode = 7=20 > packet, it fails to specify it for mode 6 packets: >> "Version Number (VN): This is a three-bit integer indicating a minimum = NTP=20 > version number. NTP servers do not respond to control messages with = an=20 > unrecognized version number. Requests may intentionally use a lower = version=20 > number to enable interoperability with earlier versions of NTP. = Responses=20 > carry the same version as the corresponding request.": What is the = version=20 > number the draft specifies? Obviously the first NTP version to support a = mode=20 > 6 or 7 packet is version 2. >=20 > The minimum version would be 2. Given that there doesn't seem to be any > interest in adding new mode 6 commands, I didn't see a need to specify a > version number for this document. If it would help, I could indicate > that this document specifies mode 6 commands for version 4 (and = earlier). As I indicated, the problem is not only the assigned command numbers = (opcode), but also the interpretation of some status words: Maybe try to = add a section on how to find out what status format the server being = queried does send back. Maybe then you'll see my problem... ;-) >=20 >> As the definition of the Clock (Radio) Status word is quite different=20= > between NTPv3 and NTPv4 (just as the System Event Code is) I wonder how = a=20 > conforming implementation will handle the VN transmitted in the = request=20 > packet: Will it respond with the correct packet regarding NV, will it = flag=20 > obsolete requests as an error (the current implementation does not), or = will=20 > it always return the current format? ("will" obviously should either = "SHOULD"=20 > or "MUST" in a specification) >>=20 >=20 > That is a good point for the WG to discuss. The goal of this document > was to ensure a stable reference for mode 6 commands that were > originally described in RFC 1305 (since obsoleted). My view is that it > should return the format that matches the version number, but I do not > maintain an NTP implementation, so this should be discussed. Also the opcodes specified are more than those of RFC1305. >=20 >> On page 6: "Each request uses a different sequence number.": Is this = a=20 > recommendation (SHOULD) or a requirement (MUST)? Obviously it should = help=20 > against spurious packets being received (or for multiple outstanding = requests=20 > when the order of packets received may vary). >=20 > I think this needs to be a MUST statement. That particular text was > lifted directly out of 1305 before the introduction of 2119 keywords. >=20 >>=20 >> An unanswered issue is how to find out what version the remote party=20 > supports, i.e. how to find out whether the remote party is NTPv3 or = NTPv4=20 > (for example). Reading variable "version" with a low VN to guess the = version=20 > will fail on Solaris for example, where the daemon does not return a = version=20 > string... >=20 > To me, that is adding a new feature/command to mode 6 to perform version > discovery. Is that necessary? I think yes, because the alternatives are ugly. Here are snipplets from some Perl code I wrote years ago: my $NTPv4 =3D $vars->has_variable('frequency'); # NTPv4 or = newer? =20 [...] # guess NTP version $control =3D NTP_Control->new($ht); if (my $vars =3D $control->read_vars(0, 'version')) { my $ver =3D $vars->variable('version') // ''; if ($ver =3D~ /^x?ntp[^\d]*(\d)(?:\.\d)/) { $ht->ntp_version($1); ::Log(0, 'D', $logger, "NTP version found to be", $ht->ntp_version(), "($ver)") if ($debug > 2); } else { ::Log(0, 'E', $logger, "Failed to parse version: $ver"); } } else { ::Log(0, 'E', $logger, 'Failed to query NTP version for', $ht->host_sock_string()); goto out; # no response, probably no NTP } And not to talk about the mess with variable names: if (!$NTPv4) { $vars->set_variable('frequency', $vars->variable('freq') / = 1000); $vars->set_variable('offset', $vars->variable('phase')); $vars->set_variable('noise', $vars->variable('error')); $vars->set_variable('jitter', 0); $vars->set_variable('stability', '0'); } else { # ntpd 4.2.6p2 "introduces" "new" variables $vars->copy_variable('rootdispersion', 'rootdisp'); $vars->copy_variable('noise', 'clk_jitter'); $vars->copy_variable('jitter', 'sys_jitter'); $vars->copy_variable('stability', 'clk_wander'); $vars->copy_variable('poll', 'tc'); # ntpd 4.2.8 also has new variables # "clk_jitter" (CS_ERROR), Regards, Ulrich From ntp-bounces@ietf.org Fri Sep 1 07:29:14 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1AD1341EF; Fri, 1 Sep 2017 07:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504276154; bh=dg/VKiRnDdqK6iwwyvc9hNwGkLhuhxsCKlaB7yxf2Ns=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=xl1QpFFxmt4cpQrggrPe4DZ8su8rD+Ku4qFxjFMx3D8qP9DFOF78fDWs8uUewfwB4 L41vPova3GI/BCoCqzjrvhCvlqcgk1JLzEPzoi7wj5HsujSoEIF/Ul8c5nDVQF4DkQ hH0h8oftKT/EE3zOUILPWTr0R5vEnp/vckko/YEg= 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 CB95C1338E3 for ; Fri, 1 Sep 2017 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 y8aknMS5Ri7s for ; Fri, 1 Sep 2017 07:29:09 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 07C12133121 for ; Fri, 1 Sep 2017 07:29:08 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o63so1701357qkb.3 for ; Fri, 01 Sep 2017 07:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b02sFEkvbe7Du3gWeB5Gagy5u35NacrFdgBEgbBxHpc=; b=HxV+JiXK2b4+IryviAFry3i5lUXhTCksoSZpZ9rHEimUmMg5jjBDIlWXW5Yu5xCB6V 7ZI+hAkFXHiKqmTh9pN+5/gzZl67/AcXY7da22Vs/nvsZYxKIsJG9rAAaAl/fCMHgEQo XCE/Nqt1/TSQfJyp6eLKFsJ3XkQbQCtUAiKWg= 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:content-transfer-encoding; bh=b02sFEkvbe7Du3gWeB5Gagy5u35NacrFdgBEgbBxHpc=; b=moxRJONZbCqdG8Ph627pXIZXinfePGtflmbIWP9fMgeInRMPmca5QGS8bXhL0LVH8V NbcanUtwmmeKfdmmA+EGeftVaOmBpFlez0oojb9tkdwOZcx4avUBW/ydPzOeQJLfcE7F 4yG06ySfMno8adpoEiyuDXriuNhHmCXojIEP+HtgHBm2LzMekweBBWHkO9VIGXTP/JAI m4wRrKKnz7Ue/UsJ+RfXWUAzgU+MoV0h5Pf6sbduLfcIxzP+SOAlblXZ0h3e+cWUDJLG n2HhDSZyGzR2+OM9ytrcahMcJo8HbDrTGFZ0CDCKvjpN4O9k+O2u4PGDEo04OMMdMoBX vniQ== X-Gm-Message-State: AHPjjUhik+g2pnG4d2YNTl6brBFN4Yhx8qz2StbcQyl6vlTrE8sftx+V Ka4o24rU5amSIKWdI7hWx2Du9+/E+tSp X-Google-Smtp-Source: ADKCNb7cBqoTjQb0Gyy/NDcYLmZ1rbz7x4IQdpSAIaQlead4821W21W+0JEHPJ9LQdbUjrWKCBkMUUd38nvo07u4AA8= X-Received: by 10.55.221.68 with SMTP id n65mr2937571qki.107.1504276147539; Fri, 01 Sep 2017 07:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 07:29:06 -0700 (PDT) X-Originating-IP: [209.118.251.3] In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Kyle Rose Date: Fri, 1 Sep 2017 10:29:06 -0400 Message-ID: To: "Karen O'Donoghue" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" SSBhbSBzdHJvbmdseSBpbiBmYXZvciBvZiBtb3ZpbmcgdGhpcyBkcmFmdCB0b3dhcmQgc3RhbmRh cmRpemF0aW9uLgpUaGlzIGlzIHRyZW1lbmRvdXMgd29yayB0aGF0IHdpbGwgZWxpbWluYXRlIGVu dGlyZSBjbGFzc2VzIG9mIGF0dGFja3MKYWdhaW5zdCBwcm90b2NvbHMgdGhhdCBkZXBlbmQgb24g c3luY2hyb25pemVkIHRpbWUuCgpBIGZldyBjb21tZW50czoKCigxKSBJIGNvdWxkbid0IGZpZ3Vy ZSBvdXQgaWYgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBjbGllbnQgdG8gcmVxdWVzdAptdWx0aXBs ZSBjb29raWVzIHdpdGggdGltZSBzeW5jaHJvbml6YXRpb24gcmVxdWVzdHMuIElmIGl0IGlzbid0 LCBpdApzZWVtcyBsaWtlIGl0IHNob3VsZCBiZSB0byBhdm9pZCB0aGUgaW5ldml0YWJsZSByZS1l c3RhYmxpc2htZW50IG9mCmtleXMgaWYgdGhlIGNsaWVudCdzIGNvb2tpZSBwb29sIHBlcm1hbmVu dGx5IGRyb3BzIGJ5IG9uZSBldmVyeSB0aW1lIGEKcGFja2V0IGlzIGxvc3QuIEJlaW5nIGFibGUg dG8gcmVxdWVzdCBtb3JlIHRoYW4gb25lIGNvb2tpZSB3aWxsIGVuYWJsZQp0aGUgY2xpZW50IHRv IG1haW50YWluIHRoZSByZWNvbW1lbmRlZCBwb29sIG9mIDguCgooMikgSW4gc2VjdGlvbiA1LCB0 aGUgZGVzY3JpcHRpb24gb2YgdGhlIHJlY29yZCB0eXBlIGZpZWxkIHNlZW1zCndyb25nLiBJdCBz YXlzIHEoIEEgMTUtYml0IGludGVnZXIgaW4gbmV0d29yayBieXRlIG9yZGVyIChmcm9tCm1vc3Qt dG8tbGVhc3Qgc2lnbmlmaWNhbnQsIGl0cyBiaXRzIGFyZSByZWNvcmQgYml0cyA3LTEgYW5kIHRo ZW4KMTUtOCkuICkuIFRoaXMgc2VlbXMgdG8gaW1wbHkgdGhhdCAoZm9yIGV4YW1wbGUpIHRoZSB2 YWx1ZSAxNjM4NSB3b3VsZApiZSBlbmNvZGVkIGFzIDAwMDAwMDEwMDAwMDAwMSB3aGVuIHJlYWQg ZnJvbSBsZWZ0LXRvLXJpZ2h0IGluIHRoZQpnaXZlbiBkaWFncmFtLCB3aGVuIEkgYmVsaWV2ZSBp dCBzaG91bGQgYmUgZW5jb2RlZCBhcyAxMDAwMDAwMDAwMDAwMDEuCkkgd291bGQganVzdCBsb3Nl IGV2ZXJ5dGhpbmcgYmV0d2VlbiB0aGUgcGFyZW50aGVzZXM6IGl0IHNlZW1zCnN1ZmZpY2llbnQg dG8gc2F5IHRoYXQgcmVjb3JkIHR5cGUgaXMgYSAxNS1iaXQgdW5zaWduZWQgaW50ZWdlciBpbgpO Qk8uCgooMykgU2VjdGlvbiA1LjIgc3RhdGVzIHRoYXQga2V5IG1hdGVyaWFsICJTSEFMTCIgYmUg ZXh0cmFjdGVkCmFjY29yZGluZyB0byBSRkMgNTcwNS4gV2hhdCBpcyB0aGUgcGxhbiBpZiBzb21l IFRMUyAxLjMtc3BlY2lmaWMKbWVjaGFuaXNtIGRlcHJlY2F0ZXMgNTcwNT8KCkt5bGUKCk9uIFdl ZCwgQXVnIDksIDIwMTcgYXQgMTI6NDEgQU0sIEthcmVuIE8nRG9ub2dodWUgPG9kb25vZ2h1ZUBp c29jLm9yZz4gd3JvdGU6Cj4gRm9sa3MsCj4KPiBUaGlzIGJlZ2lucyBhIHRocmVlIHdlZWsgd29y a2luZyBncm91cCBsYXN0IGNhbGwgKFdHTEMpIGZvciAiTmV0d29yayBUaW1lIFNlY3VyaXR5IGZv ciB0aGUgTmV0d29yayBUaW1lIFByb3RvY29s4oCdLgo+Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAtdXNpbmctbnRzLWZvci1udHAvCj4KPiBQbGVhc2Ug cmV2aWV3IGFuZCBwcm92aWRlIGNvbW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgYnkgbm8gbGF0 ZXIgdGhhbiAzMSBBdWd1c3QgMjAxNy4gRWFybGllciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB3 b3VsZCBiZSBhcHByZWNpYXRlZC4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgY2hhaXJzIHdpbGwgYmUg dXNpbmcgdGhpcyBXR0xDIHRvIGRldGVybWluZSBjb25zZW5zdXMgdG8gbW92ZSB0aGlzIGRvY3Vt ZW50IGZvcndhcmQgdG8gdGhlIElFU0cuCj4KPiBBbHNvLCBhcyBhIHJlbWluZGVyLCB3ZSBoYXZl IG1pZ3JhdGVkIHRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCB0byBJRVRGIGluZnJhc3Ry dWN0dXJlLiBQbGVhc2UgcmVzcG9uZCB0byBudHBAaWV0Zi5vcmcuIF0KPgo+IFJlZ2FyZHMsCj4g S2FyZW4gYW5kIERpZXRlcgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4gbnRwIG1haWxpbmcgbGlzdAo+IG50cEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRwCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpudHAgbWFpbGluZyBsaXN0Cm50cEBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL250cAo= From nobody Fri Sep 1 07:29:18 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 CB95C1338E3 for ; Fri, 1 Sep 2017 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 y8aknMS5Ri7s for ; Fri, 1 Sep 2017 07:29:09 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 07C12133121 for ; Fri, 1 Sep 2017 07:29:08 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o63so1701357qkb.3 for ; Fri, 01 Sep 2017 07:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b02sFEkvbe7Du3gWeB5Gagy5u35NacrFdgBEgbBxHpc=; b=HxV+JiXK2b4+IryviAFry3i5lUXhTCksoSZpZ9rHEimUmMg5jjBDIlWXW5Yu5xCB6V 7ZI+hAkFXHiKqmTh9pN+5/gzZl67/AcXY7da22Vs/nvsZYxKIsJG9rAAaAl/fCMHgEQo XCE/Nqt1/TSQfJyp6eLKFsJ3XkQbQCtUAiKWg= 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:content-transfer-encoding; bh=b02sFEkvbe7Du3gWeB5Gagy5u35NacrFdgBEgbBxHpc=; b=moxRJONZbCqdG8Ph627pXIZXinfePGtflmbIWP9fMgeInRMPmca5QGS8bXhL0LVH8V NbcanUtwmmeKfdmmA+EGeftVaOmBpFlez0oojb9tkdwOZcx4avUBW/ydPzOeQJLfcE7F 4yG06ySfMno8adpoEiyuDXriuNhHmCXojIEP+HtgHBm2LzMekweBBWHkO9VIGXTP/JAI m4wRrKKnz7Ue/UsJ+RfXWUAzgU+MoV0h5Pf6sbduLfcIxzP+SOAlblXZ0h3e+cWUDJLG n2HhDSZyGzR2+OM9ytrcahMcJo8HbDrTGFZ0CDCKvjpN4O9k+O2u4PGDEo04OMMdMoBX vniQ== X-Gm-Message-State: AHPjjUhik+g2pnG4d2YNTl6brBFN4Yhx8qz2StbcQyl6vlTrE8sftx+V Ka4o24rU5amSIKWdI7hWx2Du9+/E+tSp X-Google-Smtp-Source: ADKCNb7cBqoTjQb0Gyy/NDcYLmZ1rbz7x4IQdpSAIaQlead4821W21W+0JEHPJ9LQdbUjrWKCBkMUUd38nvo07u4AA8= X-Received: by 10.55.221.68 with SMTP id n65mr2937571qki.107.1504276147539; Fri, 01 Sep 2017 07:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 07:29:06 -0700 (PDT) X-Originating-IP: [209.118.251.3] In-Reply-To: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Kyle Rose Date: Fri, 1 Sep 2017 10:29:06 -0400 Message-ID: To: "Karen O'Donoghue" Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 14:29:12 -0000 I am strongly in favor of moving this draft toward standardization. This is tremendous work that will eliminate entire classes of attacks against protocols that depend on synchronized time. A few comments: (1) I couldn't figure out if it is possible for the client to request multiple cookies with time synchronization requests. If it isn't, it seems like it should be to avoid the inevitable re-establishment of keys if the client's cookie pool permanently drops by one every time a packet is lost. Being able to request more than one cookie will enable the client to maintain the recommended pool of 8. (2) In section 5, the description of the record type field seems wrong. It says q( A 15-bit integer in network byte order (from most-to-least significant, its bits are record bits 7-1 and then 15-8). ). This seems to imply that (for example) the value 16385 would be encoded as 000000100000001 when read from left-to-right in the given diagram, when I believe it should be encoded as 100000000000001. I would just lose everything between the parentheses: it seems sufficient to say that record type is a 15-bit unsigned integer in NBO. (3) Section 5.2 states that key material "SHALL" be extracted according to RFC 5705. What is the plan if some TLS 1.3-specific mechanism deprecates 5705? Kyle On Wed, Aug 9, 2017 at 12:41 AM, Karen O'Donoghue wrot= e: > Folks, > > This begins a three week working group last call (WGLC) for "Network Time= Security for the Network Time Protocol=E2=80=9D. > > https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ > > Please review and provide comments to the mailing list by no later than 3= 1 August 2017. Earlier comments and discussion would be appreciated. Please= note that the chairs will be using this WGLC to determine consensus to mov= e this document forward to the IESG. > > Also, as a reminder, we have migrated the working group mailing list to I= ETF infrastructure. Please respond to ntp@ietf.org. ] > > Regards, > Karen and Dieter > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Fri Sep 1 07:32:42 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43726133297; Fri, 1 Sep 2017 07:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504276362; bh=+knnKXR+A5Ice6QQ9yYZ7Np/hYbAkRJV8l/dRXJTmrQ=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=jazycoOCmS/uSdt+w0L2upFLzLD9IlM1a811EGYUN3L3UW1/grtKhpCVNLIAQERW6 DJvRF6wcPeDafrG9TCJq1Qp0sDYPuFhGwGrYfCdj56Gj+I5OPVIbdo525kVy1hGaaC +01baB6KZfEqYuG/aAD2hT1Z/QNQejEgrKG64rkU= 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 9AC84133133 for ; Fri, 1 Sep 2017 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 j7JNqBlKY-gx for ; Fri, 1 Sep 2017 07:32:38 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 EF99A13311F for ; Fri, 1 Sep 2017 07:32:37 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id k126so1734208qkb.4 for ; Fri, 01 Sep 2017 07:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ci9XCcnkzloBotCgRudMPrHyYEWZl2uitB8pmXDk8Yg=; b=bFJb3H0MIvVFpRX4Tos+1LwVVx4JWAr5G94gmXL7dIEjeIcHYMBwqE3W5fId/6EEW8 L4pi1YysENtIkSLWfTMqXhUiOSjxQJhmGH04M+mSxplQUQ63FXPbKg9Se8qxfEd4ANwC xKKi2o1aTDjvnN+iPP5dzcPh/sbjmsY3UoiGI= 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=Ci9XCcnkzloBotCgRudMPrHyYEWZl2uitB8pmXDk8Yg=; b=qg6sXN3D+mQtGGBPCk3o7nCe6h0jvNa/SDp1ftOCJZKpLc+ULjKn5SHUSsS1DLih4t aV0GfA2cASQ+a9/PyN8PVsbMnfKNRhUdsoUjq6KNaPvMmrfNb3wYFQ8xA+N4kNHO+aGX /GtNL54Hakkxf1DYekovtdpyo02Tre1CtAo/uXiu27jwywHMeEVtJgn8UMS4Je19mG4s JOlPZZT9NU/hXgYC/rc+pw0jTPXEIzgEbHVq7AxrvnBBPe+2OGSGs33iD6IhzwBiqoIq C53/xpOO8H0ESbiq3cZj6FQFJsyj3lT4AeGgWD4WiBiM0kWsJNZfnsTk9S6f6Y0Vq+fW k3Pg== X-Gm-Message-State: AHPjjUjxD3STV4140zelY2T30RPmUEfpM7b38b5AKyASEvUkwvuzZHBU PQ7wC89RBTMIFveqGhvmjZ4RGGhQsTx7 X-Google-Smtp-Source: ADKCNb5cofZccvljFOxUgr2pvBZ650q3YGIrzr73U5q6y6Jjit1Jij/h7FmUMMZLbcwzsXNhK1rvWhYmF/AOWWbIvNk= X-Received: by 10.55.159.210 with SMTP id i201mr1420968qke.80.1504276356998; Fri, 01 Sep 2017 07:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 07:32:36 -0700 (PDT) X-Originating-IP: [209.118.251.3] In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Kyle Rose Date: Fri, 1 Sep 2017 10:32:36 -0400 Message-ID: To: "Karen O'Donoghue" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On Fri, Sep 1, 2017 at 10:29 AM, Kyle Rose wrote: > be encoded as 000000100000001 when read from left-to-right in the Er, I mean 000000110000000. Either way, still seems wrong. Kyle _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Fri Sep 1 07:32: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 9AC84133133 for ; Fri, 1 Sep 2017 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 j7JNqBlKY-gx for ; Fri, 1 Sep 2017 07:32:38 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 EF99A13311F for ; Fri, 1 Sep 2017 07:32:37 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id k126so1734208qkb.4 for ; Fri, 01 Sep 2017 07:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ci9XCcnkzloBotCgRudMPrHyYEWZl2uitB8pmXDk8Yg=; b=bFJb3H0MIvVFpRX4Tos+1LwVVx4JWAr5G94gmXL7dIEjeIcHYMBwqE3W5fId/6EEW8 L4pi1YysENtIkSLWfTMqXhUiOSjxQJhmGH04M+mSxplQUQ63FXPbKg9Se8qxfEd4ANwC xKKi2o1aTDjvnN+iPP5dzcPh/sbjmsY3UoiGI= 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=Ci9XCcnkzloBotCgRudMPrHyYEWZl2uitB8pmXDk8Yg=; b=qg6sXN3D+mQtGGBPCk3o7nCe6h0jvNa/SDp1ftOCJZKpLc+ULjKn5SHUSsS1DLih4t aV0GfA2cASQ+a9/PyN8PVsbMnfKNRhUdsoUjq6KNaPvMmrfNb3wYFQ8xA+N4kNHO+aGX /GtNL54Hakkxf1DYekovtdpyo02Tre1CtAo/uXiu27jwywHMeEVtJgn8UMS4Je19mG4s JOlPZZT9NU/hXgYC/rc+pw0jTPXEIzgEbHVq7AxrvnBBPe+2OGSGs33iD6IhzwBiqoIq C53/xpOO8H0ESbiq3cZj6FQFJsyj3lT4AeGgWD4WiBiM0kWsJNZfnsTk9S6f6Y0Vq+fW k3Pg== X-Gm-Message-State: AHPjjUjxD3STV4140zelY2T30RPmUEfpM7b38b5AKyASEvUkwvuzZHBU PQ7wC89RBTMIFveqGhvmjZ4RGGhQsTx7 X-Google-Smtp-Source: ADKCNb5cofZccvljFOxUgr2pvBZ650q3YGIrzr73U5q6y6Jjit1Jij/h7FmUMMZLbcwzsXNhK1rvWhYmF/AOWWbIvNk= X-Received: by 10.55.159.210 with SMTP id i201mr1420968qke.80.1504276356998; Fri, 01 Sep 2017 07:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 07:32:36 -0700 (PDT) X-Originating-IP: [209.118.251.3] In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Kyle Rose Date: Fri, 1 Sep 2017 10:32:36 -0400 Message-ID: To: "Karen O'Donoghue" Cc: "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 14:32:40 -0000 On Fri, Sep 1, 2017 at 10:29 AM, Kyle Rose wrote: > be encoded as 000000100000001 when read from left-to-right in the Er, I mean 000000110000000. Either way, still seems wrong. Kyle From ntp-bounces@ietf.org Fri Sep 1 07:47:08 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14302132EB4; Fri, 1 Sep 2017 07:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504277228; bh=oIf+qorJoJlVkrnVDyQMTo4Mnxygl9c5vUTXiBRhDlc=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=OzvqtpZoomsZBfgzLu7tTP4OlmyxvlmdCH+1N1ovj3+ka2xiwR8sFWTjGql02fwUy C3GB0IjE97VEHkNFnf/iP/SqiUw8pjxl7RRN8Cf3HRBBDRT1MnATLOYlpPPUtToVRe hpKcBbWTLLn2n57RKz2UmZZBHFGp0M9Ikw/zuMrY= 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 37617132EB4 for ; Fri, 1 Sep 2017 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (2048-bit key) header.d=akamai.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 X-7dt_fvmo95 for ; Fri, 1 Sep 2017 07:47:04 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7852F1341F6 for ; Fri, 1 Sep 2017 07:47:04 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by m0122330.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v81EgeZO019094; Fri, 1 Sep 2017 15:47:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MboFuHM3mfm97xWFQPUSs8x4H3k+mXHtutmfY79n+dI=; b=F8jb3gMVp3O6LzampC/j2V/JJc9mEjF6adx35QMCQuFi39IE85t5wHmiXAuAprd7w0Uj Mw0UxmXHcJ+BEWHPN1vHbH/xQhLsuBVNRdF0+feRXVrRtjWKnEwCYhm+7UKtMHmvaOhx qkFf99gJlHvO9UmJ262bLCI/1Rl2buKUhlTjPpns7KW6r89E0LEdSNZ+DoW1mQFnRgYW dauEJ6fQ1pyox1UvgR9yQtjbHaExg4E4v19olsO3Mc0TX/NH0Cton31mLy1E3Jd5R/qJ 0tCr+UzIGVrxJ/oPvnhsED48nK6LhQPNa5CAPqQrMmH80FhLjs/WZEooix3Rh7UkCFwd Ig== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2cq8h489fw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Sep 2017 15:47:00 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v81EkOLa009365; Fri, 1 Sep 2017 10:46:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2cp60rvek3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 01 Sep 2017 10:46:59 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Sep 2017 09:46:58 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 1 Sep 2017 09:46:58 -0500 From: "Salz, Rich" To: Miroslav Lichvar , Daniel Franke Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKepVSAgAA3xACAAMdqAIAAgYcAgAArdwA= Date: Fri, 1 Sep 2017 14:46:57 +0000 Message-ID: <42F96340-5909-4AFD-90F7-2BB43B3A3562@akamai.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> <20170901081122.GX11067@localhost> In-Reply-To: <20170901081122.GX11067@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.255] Content-ID: <59DB7CFE3A007F479DC2473B4420D8FB@akamai.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709010210 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709010209 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , Sharon Goldberg Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" 4p6iICAgICBJIHRoaW5rIGl0IGRvZXMgY2xlYXIgdXAgdGhlIGlzc3VlIHdpdGggdHdvIGFjdGl2 ZSBwZWVycy4gVGhhbmtzLiBJdA0KICAgIGRvZXNuJ3QgY2hhbmdlIG15IHZvdGUsIGhvd2V2ZXIu DQogICAgDQpJIHN1Z2dlc3Qgd2UgdHJ5IHRvIGF2b2lkIHVzaW5nIHRoZSB3b3JkIOKAnHZvdGXi gJ0gaGVyZS4gIFdlIHdvcmsgYnkgcm91Z2ggY29uc2Vuc3VzLCB3ZSBkb27igJl0IGNvdW50IHZv dGVzLiAgSXQgaXMgdXAgdG8gdGhlIGNoYWlycyB0byBkZXRlcm1pbmUgY29uc2Vuc3VzIGlmIGl0 4oCZcyBub3Qg4oCcb2J2aW91c+KAnSAoZm9yIHNvbWUgZGVmaW5pdGlvbiBvZiB0aGUgd29yZCku IA0KDQpJdCBtaWdodCBzZWVtIGxpa2UgYSBtaW5vciB0aGluZywgYnV0IEkgZG9u4oCZdCB0aGlu ayBpdCBpcy4gIOKAnEkgdm90ZSBhZ2FpbnN04oCdIGlzIGRpZmZlcmVudCBmcm9tIOKAnEnigJlt IG9wcG9zZWQs4oCdIGJvdGggZnJvbSBhIG1pbmRzZXQgYW5kIHByb2NlZHVyYWwgdmlld3BvaW50 Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpudHAg bWFpbGluZyBsaXN0Cm50cEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL250cAo= From nobody Fri Sep 1 07:47:08 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 37617132EB4 for ; Fri, 1 Sep 2017 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (2048-bit key) header.d=akamai.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 X-7dt_fvmo95 for ; Fri, 1 Sep 2017 07:47:04 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7852F1341F6 for ; Fri, 1 Sep 2017 07:47:04 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by m0122330.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v81EgeZO019094; Fri, 1 Sep 2017 15:47:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MboFuHM3mfm97xWFQPUSs8x4H3k+mXHtutmfY79n+dI=; b=F8jb3gMVp3O6LzampC/j2V/JJc9mEjF6adx35QMCQuFi39IE85t5wHmiXAuAprd7w0Uj Mw0UxmXHcJ+BEWHPN1vHbH/xQhLsuBVNRdF0+feRXVrRtjWKnEwCYhm+7UKtMHmvaOhx qkFf99gJlHvO9UmJ262bLCI/1Rl2buKUhlTjPpns7KW6r89E0LEdSNZ+DoW1mQFnRgYW dauEJ6fQ1pyox1UvgR9yQtjbHaExg4E4v19olsO3Mc0TX/NH0Cton31mLy1E3Jd5R/qJ 0tCr+UzIGVrxJ/oPvnhsED48nK6LhQPNa5CAPqQrMmH80FhLjs/WZEooix3Rh7UkCFwd Ig== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2cq8h489fw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Sep 2017 15:47:00 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v81EkOLa009365; Fri, 1 Sep 2017 10:46:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2cp60rvek3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 01 Sep 2017 10:46:59 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Sep 2017 09:46:58 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 1 Sep 2017 09:46:58 -0500 From: "Salz, Rich" To: Miroslav Lichvar , Daniel Franke CC: "ntp@ietf.org" , Sharon Goldberg Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKepVSAgAA3xACAAMdqAIAAgYcAgAArdwA= Date: Fri, 1 Sep 2017 14:46:57 +0000 Message-ID: <42F96340-5909-4AFD-90F7-2BB43B3A3562@akamai.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <20170831091427.GT11067@localhost> <20170901081122.GX11067@localhost> In-Reply-To: <20170901081122.GX11067@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.255] Content-Type: text/plain; charset="utf-8" Content-ID: <59DB7CFE3A007F479DC2473B4420D8FB@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709010210 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709010209 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 14:47:06 -0000 4p6iICAgICBJIHRoaW5rIGl0IGRvZXMgY2xlYXIgdXAgdGhlIGlzc3VlIHdpdGggdHdvIGFjdGl2 ZSBwZWVycy4gVGhhbmtzLiBJdA0KICAgIGRvZXNuJ3QgY2hhbmdlIG15IHZvdGUsIGhvd2V2ZXIu DQogICAgDQpJIHN1Z2dlc3Qgd2UgdHJ5IHRvIGF2b2lkIHVzaW5nIHRoZSB3b3JkIOKAnHZvdGXi gJ0gaGVyZS4gIFdlIHdvcmsgYnkgcm91Z2ggY29uc2Vuc3VzLCB3ZSBkb27igJl0IGNvdW50IHZv dGVzLiAgSXQgaXMgdXAgdG8gdGhlIGNoYWlycyB0byBkZXRlcm1pbmUgY29uc2Vuc3VzIGlmIGl0 4oCZcyBub3Qg4oCcb2J2aW91c+KAnSAoZm9yIHNvbWUgZGVmaW5pdGlvbiBvZiB0aGUgd29yZCku IA0KDQpJdCBtaWdodCBzZWVtIGxpa2UgYSBtaW5vciB0aGluZywgYnV0IEkgZG9u4oCZdCB0aGlu ayBpdCBpcy4gIOKAnEkgdm90ZSBhZ2FpbnN04oCdIGlzIGRpZmZlcmVudCBmcm9tIOKAnEnigJlt IG9wcG9zZWQs4oCdIGJvdGggZnJvbSBhIG1pbmRzZXQgYW5kIHByb2NlZHVyYWwgdmlld3BvaW50 Lg0KDQo= From nobody Fri Sep 1 08:11: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 7E47C133122 for ; Fri, 1 Sep 2017 08:11:50 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 qWJMkwFns6Uu for ; Fri, 1 Sep 2017 08:11:48 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 9C74F1342BE for ; Fri, 1 Sep 2017 08:11:48 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id u26so3282574wma.0 for ; Fri, 01 Sep 2017 08:11:48 -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=FchSIM53KNSR/N5M7OZlu4EzPa7JvIBFZ6FUBVDYL3k=; b=tsGXYDzGgGTRqMa3WM29D/FWN2RcA6CzHPc1sYc1i/MX21PO+9/vqVF52C4+dja9oH 0piPzx63J6ini37DiY7UXtDz/1gAS0vte2g/qctyJfMpOB2n/GuUOFbbFI0prtHyztYy yOs8pghNIOkxB7HfkyYZKyfTTI8q5+EP4MxKP/oKiRcZEYmZpUFAf0eBgiQQ+4FEYMOb GcJFgXiZICB4FSaIAq4EkNm3R8zzvA+njTe5VMbyjipHXYBfzLB0BRMp6JCsnaF/+BXI K5JWqPe5Mbj3nmueCZljc8LUYR7ePAvtNofbXi65xvy03MOYL5LhcyX3fqXjfNMPPAR1 u9Sw== 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=FchSIM53KNSR/N5M7OZlu4EzPa7JvIBFZ6FUBVDYL3k=; b=YVDC06ojNmWTMyZI5eQT5UuAz7uJOhbeunqz9x3jftyIN4hb6bC96T3uJDBR3Jq/mW D79Xe/gHz71gr/yyGbuu/kZZONtDZKOIuu8MFElUGSkB6JvA5nzZvsurfEocESfVFqu7 uTGRHGTwrQrFX7SEK3hf6JHNTkTuoDl3RRadwytcQtIBFY1i62YMTSca7kt1yGUjWg8V wiWnvlSkgSH78KlPPQSLSCrqr3i9pPGLbzXrWBKZ2X0kCRZhKWgtlMXhJM9x6rNqsH6N Drkr9+fiOwwnh6NiwQfTnDtx80gn8srOe+1WFQ4ZxQLlNGr3DJQHLnxJiawyKDnS2yrQ oL2Q== X-Gm-Message-State: AHPjjUirLX1eUC+SCr+mlZ5vit2rGOs9gLiooY35fxRv7MrxwEki0gBG AVw6vw6SXX2woUvuU7sjE6KC3BiNfzsv X-Google-Smtp-Source: ADKCNb6MmF3/hWScSjkIde1NsuKsY0/hRFWUmfsTSXdx3tWVrIsQ5qX4+IliJcG4/iONqxZrJDFPgF6FsfJswNWItS8= X-Received: by 10.80.134.251 with SMTP id 56mr1973306edu.19.1504278706841; Fri, 01 Sep 2017 08:11:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 08:11:46 -0700 (PDT) In-Reply-To: <20170901101255.8E05340605C@ip-64-139-1-69.sjc.megapath.net> References: <20170901101255.8E05340605C@ip-64-139-1-69.sjc.megapath.net> From: Daniel Franke Date: Fri, 1 Sep 2017 11:11:46 -0400 Message-ID: To: Hal Murray Cc: ntp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] TLS for NTS for NTP 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: Fri, 01 Sep 2017 15:11:50 -0000 On 9/1/17, Hal Murray wrote: > I'm trying to understand the big picture. > > The typical protocol flow for client/server says the client uses TCP to do a > > TLS handshake. (It's about 1/3 of the way down on page 5 of draft 09.) > > How complicated is that? Remember that we have to do this without knowing > the time. > I assume most implementations will be using some TLS package. Can somebody > give me a quick lesson in TLS? This is not something I can really cover in a few paragraphs, but I recommend Ivan Ristic's book. https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > Is there a solid package that runs on most OSes? Is the API clean? Yes. OpenSSL is the most widely used, but there are several dozen alternatives. > Can it handle the time-not-known case? The only place that TLS needs time is when checking whether the presented X.509 certificate is expired. See section 9.2 about that. > That paragraph says "only one round trip". Is that after the TLS setup, or > can it be piggybacked on TLS so that TLS+NTS is only one round trip? It's after TLS setup, but with TLS False Start (RFC 7918) the first part of the NTS-KE negotiation takes place in the same round trip as the last part of the handshake. In sum it ends up looking like this: Client: TCP SYN Server: TCP SYN/ACK (No server state required so far, if the server uses SYN cookies) Client: TCP ACK, TLS ClientHello Server: TLS ServerHello, TLS Certificate, TLS ServerKeyExchange, TLS ServerHelloDone (Server state required here) Client: TLS ClientKeyExchange, TLS ChangeCipherSpec, TLS Finished, NTS-KE request as TLS Application Data. Server: TLS ChangeCipherSpec, TLS Finished, NTS-KE response (Server discards state) > TLS needs certificates. Do we want to piggyback on the root certificates > distributed with most OSes, or do we want the admin setting things up to > provide certificates for the servers they select? It certainly has to be configurable. Totally up to distro maintainers what the default configuration is. > How much would already having the right certificates simplify the TLS code? Irrelevant, since nobody's going to be writing their own TLS stack just to implement NTS. But OpenSSL's chain verification code is about 3KLOC. > Is this going to work OK on IoT devices? > > How about spares that have been sitting on the shelf for a long time? There are lots of TLS implementations targeting embedded devices a lot smaller than the chaps they're putting in most IoT gizmos. TLS has been around since the 90s, and even notwithstanding hardware improvements, the algorithms we've got now are a lot cheaper than the ones we had then. From ntp-bounces@ietf.org Fri Sep 1 08:11:52 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 208C7133122; Fri, 1 Sep 2017 08:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504278712; bh=IPPk6WVe07YIoeV6Ym1tWu8jKE3uCs/CyC9liI6yYkA=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=fjkE8HBYJ5LTU6hrndEqtEyUNDWi3xSwnmzOy8jvMVx49HyFp/5pS6ZNyWn7vAkkv kFU41aBwKEUJIxngzyShhzZEbKqcopyQ+A6VWnERa9snv9ZTD9gmTFSuxLNDczMTVi xqLGCdyeIefgT79sWJDRncVA2OB+pdz2EZPhMgFQ= 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 7E47C133122 for ; Fri, 1 Sep 2017 08:11:50 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 qWJMkwFns6Uu for ; Fri, 1 Sep 2017 08:11:48 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 9C74F1342BE for ; Fri, 1 Sep 2017 08:11:48 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id u26so3282574wma.0 for ; Fri, 01 Sep 2017 08:11:48 -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=FchSIM53KNSR/N5M7OZlu4EzPa7JvIBFZ6FUBVDYL3k=; b=tsGXYDzGgGTRqMa3WM29D/FWN2RcA6CzHPc1sYc1i/MX21PO+9/vqVF52C4+dja9oH 0piPzx63J6ini37DiY7UXtDz/1gAS0vte2g/qctyJfMpOB2n/GuUOFbbFI0prtHyztYy yOs8pghNIOkxB7HfkyYZKyfTTI8q5+EP4MxKP/oKiRcZEYmZpUFAf0eBgiQQ+4FEYMOb GcJFgXiZICB4FSaIAq4EkNm3R8zzvA+njTe5VMbyjipHXYBfzLB0BRMp6JCsnaF/+BXI K5JWqPe5Mbj3nmueCZljc8LUYR7ePAvtNofbXi65xvy03MOYL5LhcyX3fqXjfNMPPAR1 u9Sw== 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=FchSIM53KNSR/N5M7OZlu4EzPa7JvIBFZ6FUBVDYL3k=; b=YVDC06ojNmWTMyZI5eQT5UuAz7uJOhbeunqz9x3jftyIN4hb6bC96T3uJDBR3Jq/mW D79Xe/gHz71gr/yyGbuu/kZZONtDZKOIuu8MFElUGSkB6JvA5nzZvsurfEocESfVFqu7 uTGRHGTwrQrFX7SEK3hf6JHNTkTuoDl3RRadwytcQtIBFY1i62YMTSca7kt1yGUjWg8V wiWnvlSkgSH78KlPPQSLSCrqr3i9pPGLbzXrWBKZ2X0kCRZhKWgtlMXhJM9x6rNqsH6N Drkr9+fiOwwnh6NiwQfTnDtx80gn8srOe+1WFQ4ZxQLlNGr3DJQHLnxJiawyKDnS2yrQ oL2Q== X-Gm-Message-State: AHPjjUirLX1eUC+SCr+mlZ5vit2rGOs9gLiooY35fxRv7MrxwEki0gBG AVw6vw6SXX2woUvuU7sjE6KC3BiNfzsv X-Google-Smtp-Source: ADKCNb6MmF3/hWScSjkIde1NsuKsY0/hRFWUmfsTSXdx3tWVrIsQ5qX4+IliJcG4/iONqxZrJDFPgF6FsfJswNWItS8= X-Received: by 10.80.134.251 with SMTP id 56mr1973306edu.19.1504278706841; Fri, 01 Sep 2017 08:11:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 08:11:46 -0700 (PDT) In-Reply-To: <20170901101255.8E05340605C@ip-64-139-1-69.sjc.megapath.net> References: <20170901101255.8E05340605C@ip-64-139-1-69.sjc.megapath.net> From: Daniel Franke Date: Fri, 1 Sep 2017 11:11:46 -0400 Message-ID: To: Hal Murray Archived-At: Subject: Re: [Ntp] TLS for NTS for NTP 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: , Cc: ntp@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 9/1/17, Hal Murray wrote: > I'm trying to understand the big picture. > > The typical protocol flow for client/server says the client uses TCP to do a > > TLS handshake. (It's about 1/3 of the way down on page 5 of draft 09.) > > How complicated is that? Remember that we have to do this without knowing > the time. > I assume most implementations will be using some TLS package. Can somebody > give me a quick lesson in TLS? This is not something I can really cover in a few paragraphs, but I recommend Ivan Ristic's book. https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > Is there a solid package that runs on most OSes? Is the API clean? Yes. OpenSSL is the most widely used, but there are several dozen alternatives. > Can it handle the time-not-known case? The only place that TLS needs time is when checking whether the presented X.509 certificate is expired. See section 9.2 about that. > That paragraph says "only one round trip". Is that after the TLS setup, or > can it be piggybacked on TLS so that TLS+NTS is only one round trip? It's after TLS setup, but with TLS False Start (RFC 7918) the first part of the NTS-KE negotiation takes place in the same round trip as the last part of the handshake. In sum it ends up looking like this: Client: TCP SYN Server: TCP SYN/ACK (No server state required so far, if the server uses SYN cookies) Client: TCP ACK, TLS ClientHello Server: TLS ServerHello, TLS Certificate, TLS ServerKeyExchange, TLS ServerHelloDone (Server state required here) Client: TLS ClientKeyExchange, TLS ChangeCipherSpec, TLS Finished, NTS-KE request as TLS Application Data. Server: TLS ChangeCipherSpec, TLS Finished, NTS-KE response (Server discards state) > TLS needs certificates. Do we want to piggyback on the root certificates > distributed with most OSes, or do we want the admin setting things up to > provide certificates for the servers they select? It certainly has to be configurable. Totally up to distro maintainers what the default configuration is. > How much would already having the right certificates simplify the TLS code? Irrelevant, since nobody's going to be writing their own TLS stack just to implement NTS. But OpenSSL's chain verification code is about 3KLOC. > Is this going to work OK on IoT devices? > > How about spares that have been sitting on the shelf for a long time? There are lots of TLS implementations targeting embedded devices a lot smaller than the chaps they're putting in most IoT gizmos. TLS has been around since the 90s, and even notwithstanding hardware improvements, the algorithms we've got now are a lot cheaper than the ones we had then. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Fri Sep 1 08:25:59 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D058C134284; Fri, 1 Sep 2017 08:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504279558; bh=SB4ZJhFvYU+c1AY0SIL0BCxAOq3F6vi9cQTLW4eOefs=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=XZ8iEJ0ORMl7ytk1JXCR1ftpO65IU5fyj6ZPGmcMHK3jnrv8m86bVhJ9TZ+OVf5yg fVkDdEkCGoHlRJzjzrBg8kIuoA6bGy3ofwor6KWVPgECZPLayrqrF5HWnNqWuO/7ne EmLPKNG14/ZE1bAyAXrA68mEnipXUJiM5qfY1Bh8= 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 8CE9E1332D4; Fri, 1 Sep 2017 08:25:55 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 nLbs6mLT5W-o; Fri, 1 Sep 2017 08:25:53 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 8E276132DD6; Fri, 1 Sep 2017 08:25:53 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u26so3519732wma.0; Fri, 01 Sep 2017 08:25: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=397dHcjRwckg2PLBy/vQNa7ZVnEsYrHT1lBwgaVFbwk=; b=cIQH8qA2BKJRGEjHomMfItj48Lee2s/MLZfNboc0IVi9T3MHWmadV3eg4uKIcKMyiR qC1YaVNSfD34CoUd4iAV0tZzvQYFno9/TpiXkAvtH6nHi4mc/z6FxYKLk3uimYLIPidN 6OIr6/Fn8HR80Bp3trh9PsP7uN7AkekMVNTdGUS1IG3X/TS/sm+p8hiU0/377O6RHVbY wFciCSeDYHhCUgMV5qpe7cLfWdYI9akTfOfcjXwp/sF9SulYYtKB7YqA2BH0mS3e4V4S YrA1T+yln/m5NHVjuK8humgLmsKTYXGPJSu/S5IHkGPeNxweJuCyCruvmuISOzWkw4DC iPeQ== 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=397dHcjRwckg2PLBy/vQNa7ZVnEsYrHT1lBwgaVFbwk=; b=CciNv2aQr2CZP0lIPkYQJ8ZgKJncjGbvXHYgOeOdILckkoSBV2aTKnGfKhXpFHvIgv +KJ4Hmyc+UY3bpJuSU42ezxYWHc82GGn+OD1Geo0DzgRcCCmyaqDvAhF1pv5Yk7sctXi xrWmjupdjBJz3iyEyvNaqt6ENArmu3KtuJykSmg1pWsf+42RCxO8CkxVI2KzHmJEqKJu 0Cl6+/te9AOuWTe6PMGs502e1Qz+u/Bw7RdqvxsXqQJgVUlmiQai/74EmqhDYtJf6bNw 4WrjW21CKPC+hDH2594G4eQ4jKl2vgdf6RwpT4z0rGp3wVG2mB5LX8+jnaUz90bB5JVA bWMw== X-Gm-Message-State: AHPjjUipBNquEC7TIveB3zVYOy8T3UTqcniy1BqhWZoVzcR5RkLUUI8Y 0jzzCEBF1Tr7ydJOs5VKf8Bj+smK/lWk X-Google-Smtp-Source: ADKCNb7K5cfUxOC/IgGTy+5DLj9OZydlhCCNbcNsPFVk/DGcRYvQWDQOsic4Y6Mhe5Ym9eYQ3Mv/Ebxz5+/MTChPEtA= X-Received: by 10.80.159.229 with SMTP id c92mr2062355edf.257.1504279551852; Fri, 01 Sep 2017 08:25:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 08:25:51 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Daniel Franke Date: Fri, 1 Sep 2017 11:25:51 -0400 Message-ID: To: Kyle Rose Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 9/1/17, Kyle Rose wrote: > I am strongly in favor of moving this draft toward standardization. > This is tremendous work that will eliminate entire classes of attacks > against protocols that depend on synchronized time. > > A few comments: > > (1) I couldn't figure out if it is possible for the client to request > multiple cookies with time synchronization requests. If it isn't, it > seems like it should be to avoid the inevitable re-establishment of > keys if the client's cookie pool permanently drops by one every time a > packet is lost. Being able to request more than one cookie will enable > the client to maintain the recommended pool of 8. That's exactly what the NTS Cookie Placeholder extension is for. The client MAY include one or more NTS Cookie Placeholder extension field, which MUST be authenticated and MAY be encrypted. The number of NTS Cookie Placeholder extension fields that the client includes SHOULD be such that if the client includes N placeholders and the server sends back N+1 cookies, the number of unused cookies stored by the client will come to eight. When both the client and server adhere to all cookie-management guidance provided in this memo, the number of placeholder extension fields will equal the number of dropped packets since the last successful volley. > (2) In section 5, the description of the record type field seems > wrong. It says q( A 15-bit integer in network byte order (from > most-to-least significant, its bits are record bits 7-1 and then > 15-8). ). This seems to imply that (for example) the value 16385 would > be encoded as 000000100000001 when read from left-to-right in the > given diagram, when I believe it should be encoded as 100000000000001. > I would just lose everything between the parentheses: it seems > sufficient to say that record type is a 15-bit unsigned integer in > NBO. Already fixed in git. > (3) Section 5.2 states that key material "SHALL" be extracted > according to RFC 5705. What is the plan if some TLS 1.3-specific > mechanism deprecates 5705? Current TLS 1.3 drafts swaps the KDF implementation from TLS-PRF for HKDF but keep the interface exactly the same. The intent, which seems clear at least to me, is that anything which currently uses RFC 5705 will use TLS 1.3's exporter to extract keys from TLS 1.3 sessions. Once TLS 1.3 is finalized, we can publish an update to clarify this if it isn't clear enough already. If even the *interface* changed then we'd have to do an update for sure, but I think the odds of that approach nil. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Fri Sep 1 08:26:05 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 8CE9E1332D4; Fri, 1 Sep 2017 08:25:55 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 nLbs6mLT5W-o; Fri, 1 Sep 2017 08:25:53 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 8E276132DD6; Fri, 1 Sep 2017 08:25:53 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u26so3519732wma.0; Fri, 01 Sep 2017 08:25: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=397dHcjRwckg2PLBy/vQNa7ZVnEsYrHT1lBwgaVFbwk=; b=cIQH8qA2BKJRGEjHomMfItj48Lee2s/MLZfNboc0IVi9T3MHWmadV3eg4uKIcKMyiR qC1YaVNSfD34CoUd4iAV0tZzvQYFno9/TpiXkAvtH6nHi4mc/z6FxYKLk3uimYLIPidN 6OIr6/Fn8HR80Bp3trh9PsP7uN7AkekMVNTdGUS1IG3X/TS/sm+p8hiU0/377O6RHVbY wFciCSeDYHhCUgMV5qpe7cLfWdYI9akTfOfcjXwp/sF9SulYYtKB7YqA2BH0mS3e4V4S YrA1T+yln/m5NHVjuK8humgLmsKTYXGPJSu/S5IHkGPeNxweJuCyCruvmuISOzWkw4DC iPeQ== 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=397dHcjRwckg2PLBy/vQNa7ZVnEsYrHT1lBwgaVFbwk=; b=CciNv2aQr2CZP0lIPkYQJ8ZgKJncjGbvXHYgOeOdILckkoSBV2aTKnGfKhXpFHvIgv +KJ4Hmyc+UY3bpJuSU42ezxYWHc82GGn+OD1Geo0DzgRcCCmyaqDvAhF1pv5Yk7sctXi xrWmjupdjBJz3iyEyvNaqt6ENArmu3KtuJykSmg1pWsf+42RCxO8CkxVI2KzHmJEqKJu 0Cl6+/te9AOuWTe6PMGs502e1Qz+u/Bw7RdqvxsXqQJgVUlmiQai/74EmqhDYtJf6bNw 4WrjW21CKPC+hDH2594G4eQ4jKl2vgdf6RwpT4z0rGp3wVG2mB5LX8+jnaUz90bB5JVA bWMw== X-Gm-Message-State: AHPjjUipBNquEC7TIveB3zVYOy8T3UTqcniy1BqhWZoVzcR5RkLUUI8Y 0jzzCEBF1Tr7ydJOs5VKf8Bj+smK/lWk X-Google-Smtp-Source: ADKCNb7K5cfUxOC/IgGTy+5DLj9OZydlhCCNbcNsPFVk/DGcRYvQWDQOsic4Y6Mhe5Ym9eYQ3Mv/Ebxz5+/MTChPEtA= X-Received: by 10.80.159.229 with SMTP id c92mr2062355edf.257.1504279551852; Fri, 01 Sep 2017 08:25:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 08:25:51 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Daniel Franke Date: Fri, 1 Sep 2017 11:25:51 -0400 Message-ID: To: Kyle Rose Cc: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 15:25:55 -0000 On 9/1/17, Kyle Rose wrote: > I am strongly in favor of moving this draft toward standardization. > This is tremendous work that will eliminate entire classes of attacks > against protocols that depend on synchronized time. > > A few comments: > > (1) I couldn't figure out if it is possible for the client to request > multiple cookies with time synchronization requests. If it isn't, it > seems like it should be to avoid the inevitable re-establishment of > keys if the client's cookie pool permanently drops by one every time a > packet is lost. Being able to request more than one cookie will enable > the client to maintain the recommended pool of 8. That's exactly what the NTS Cookie Placeholder extension is for. The client MAY include one or more NTS Cookie Placeholder extension field, which MUST be authenticated and MAY be encrypted. The number of NTS Cookie Placeholder extension fields that the client includes SHOULD be such that if the client includes N placeholders and the server sends back N+1 cookies, the number of unused cookies stored by the client will come to eight. When both the client and server adhere to all cookie-management guidance provided in this memo, the number of placeholder extension fields will equal the number of dropped packets since the last successful volley. > (2) In section 5, the description of the record type field seems > wrong. It says q( A 15-bit integer in network byte order (from > most-to-least significant, its bits are record bits 7-1 and then > 15-8). ). This seems to imply that (for example) the value 16385 would > be encoded as 000000100000001 when read from left-to-right in the > given diagram, when I believe it should be encoded as 100000000000001. > I would just lose everything between the parentheses: it seems > sufficient to say that record type is a 15-bit unsigned integer in > NBO. Already fixed in git. > (3) Section 5.2 states that key material "SHALL" be extracted > according to RFC 5705. What is the plan if some TLS 1.3-specific > mechanism deprecates 5705? Current TLS 1.3 drafts swaps the KDF implementation from TLS-PRF for HKDF but keep the interface exactly the same. The intent, which seems clear at least to me, is that anything which currently uses RFC 5705 will use TLS 1.3's exporter to extract keys from TLS 1.3 sessions. Once TLS 1.3 is finalized, we can publish an update to clarify this if it isn't clear enough already. If even the *interface* changed then we'd have to do an update for sure, but I think the odds of that approach nil. From ntp-bounces@ietf.org Fri Sep 1 09:48:41 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 170FA134232; Fri, 1 Sep 2017 09:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504284521; bh=MQiV4wiloNINFS/f2ojDd8eN9IbKMmCzeEnW/LeRsDc=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=O8q7xp0YE9PlTeBBqRJSR5zHhd0aeWNae6peiONRMJddJEEuKYn2hXKw2vtfRsL1n nPRwRz48gS6NtK1tZut7A07rwPIP24SEav1vgDpol1/eZcKgb7KIv9f4xTh3qdq4FP xwl2MLqs+m5q+O9zuShztbdoVqn7VLYLbiCbFryo= 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 27425132E7D; Fri, 1 Sep 2017 09:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 6yGAhlNJnErX; Fri, 1 Sep 2017 09:48:37 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 CA743132DF7; Fri, 1 Sep 2017 09:48:36 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 81so4657691ioj.5; Fri, 01 Sep 2017 09:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WH8zt5ZtmL86GY7mS1veKK80ZPW2lthi4Twg9PK0Uuc=; b=KmOPIoXWgzHpYjSKQjM9as0DMnxJ+eckW0Nvzxm3Jlw3K1K2mwJBaNOO2X1J/uOzjb RaHzcYJgJVDkoyd9JtRoXgxyYsilvihIVxayNdUepPkqDvuRwzr8UM56mgkTwaD9mMgG Sh1QExLChgxQAPm7X7OvAkrdl/+V0P+oQUPYTclD2U1xZcyWuqZxKXXU5DJKYwMV3+fH SxNtdkE0ZQQtZSMOMCmAe11NHkk57BC64Fd8w9cDfpoeGObywa0uAJT0+zqmKJiOredk wx7rJSiIZ52DWjjpjtgcogSXImVvJV3IF7EE+ZVrE2UMXqVOGr//xXeuQU4sP8EwypGE e7yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WH8zt5ZtmL86GY7mS1veKK80ZPW2lthi4Twg9PK0Uuc=; b=aMsQUfaYyT9hVS5x7y1JeYyd0T2fqoDsZEDANXls6qFkFRz6i4tI85auYbpmBYK4z0 kS/VR/fVOOYsKFhzXg2DiFtd8GAlkZO0KERrdDkR1/+ocR9zXXYavRkfkzVBZVAtWMXr z+3z07xISGR+Hi3ITnt2usLK1o2HV2hp4IMYwAEN8VZS1EuLjztvzbXc12++S2Plo1t+ QqYQ+8JjptBq9/8Tm6m3L8nerxUxhkXaDc/LgT3g/PeJuQ32THRcHiBcO7XDx2nMrxBg Jp8O/fjQYrz51oVB2KwpbEhX8zX3MjI3SKNXgbRtj+v7+gspUMV3j467ZiKZGM3DRajZ X3Dg== X-Gm-Message-State: AHPjjUipkfJMOOxqCs7XUEkHhIT9u15eQ65qG9Hli1UL4N17mo2U7sgN o2MQzgZz9oHmgLrqitNaDZSgORqqCQ== X-Google-Smtp-Source: ADKCNb5AD6mY57H+5+EeH28R4ylm3ifr2HycbOwQYAI4WwwKoL+95PBm0p4lvBOL5/IpcQJbVxMHT3pYqMX6AEozO/4= X-Received: by 10.36.3.4 with SMTP id e4mr1365218ite.166.1504284516041; Fri, 01 Sep 2017 09:48:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.155.195 with HTTP; Fri, 1 Sep 2017 09:47:55 -0700 (PDT) In-Reply-To: References: From: Sharon Goldberg Date: Fri, 1 Sep 2017 12:47:55 -0400 X-Google-Sender-Auth: P_ZLgRin9xj2mw-TmiQ65BxGnQk Message-ID: To: Tal Mizrahi Archived-At: Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-ntp-mac 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: multipart/mixed; boundary="===============8740740306613449002==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============8740740306613449002== Content-Type: multipart/alternative; boundary="001a11449214384730055823882b" --001a11449214384730055823882b Content-Type: text/plain; charset="UTF-8" Hi Tal, Thanks for your comments. Major comments: > - This may have been discussed before, but still I am not sure what the > answer is: it seems to make sense to define this new MAC as a dedicated > extension field. Any reason not to do that? Since this draft deprecates the > previous MD5-based MAC, there are no backward compatibility considerations. > The draft does not require the use of a new extension field. It works with NTP's legacy MAC fields. As Harlan mentioned earlier, the key ID maps to two items--the key and the algorithm number. We decided not to introduce a new extension field to keep things simple for implementations. > - To allow algorithm agility, I would suggest to add a field that > specifies the algorithm + a corresponding IANA registry. > > This NTP MAC draft only works for the setting of a pre-shared key (PSK) for legacy NTP. For asymmetric keys, we need to use NTS. Given that we are stuck with the PSK model, we can still support algorithm agility by specifying the MAC algorithm as part of the process of configuring the PSK. Specifically, the ntp config file maps the key ID to a secret key and MAC algorithm number. > Less major comments: > - Missing security considerations section. > Yes, will add. > - Missing IANA considerations section. > Given the way we are dealing with algorithm agility, I don't think IANA considerations are relevant. > - "any extension fields that are present" => "every extension fields that > is present". > > Thanks. Sharon > On Wed, Aug 9, 2017 at 7:53 AM, Karen O'Donoghue > wrote: > >> Folks, >> >> This begins a three week working group last call (WGLC) for "Message >> Authentication Code for the Network Time Protocol" >> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ >> >> Please review and provide comments to the mailing list by no later than >> 31 August 2017. Earlier comments and discussion would be appreciated. >> Please note that the chairs will be using this WGLC to determine consensus >> to move this document forward to the IESG. >> >> Also, as a reminder, we have migrated the working group mailing list to >> IETF infrastructure. Please respond to ntp@ietf.org. >> >> Regards, >> Karen and Dieter >> >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >> >> > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a11449214384730055823882b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tal, Thanks for your comments.

Major comments:
- This may ha= ve been discussed before, but still I am not sure what the answer is: it se= ems to make sense to define this new MAC as a dedicated extension field. An= y reason not to do that? Since this draft deprecates the previous MD5-based= MAC, there are no backward compatibility considerations.

The draft does not require the = use of a new extension field. It works with NTP's legacy MAC fields.=C2= =A0 As Harlan mentioned earlier, the key ID maps to two items--the key and = the algorithm number. We decided not to introduce a new extension field to = keep things simple for implementations.
=C2=A0
- To allow algorit= hm agility, I would suggest to add a field that specifies the algorithm + a= corresponding IANA registry.

T= his NTP MAC draft only works for the setting of a pre-shared key (PSK) for = legacy NTP.

For asymmetric keys, we need to u= se NTS.

Given that we are stuck with the PSK = model, we can still support algorithm agility by specifying the MAC algorit= hm as part of the process of configuring the PSK. Specifically, the ntp con= fig file maps the key ID to a secret key and MAC algorithm number.
=C2=A0
Less major comments:
- Missing security considerations sec= tion.

Yes, will add.
<= div>=C2=A0
- Miss= ing IANA considerations section.

Given the way we are dealing with algorithm agility, I don't think IA= NA considerations are relevant.
=C2=A0
- "any extension fields that are p= resent" =3D> "every extension fields that is present".

Thanks.
Sharon


On Wed, Aug 9= , 2017 at 7:53 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:
Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG.=C2=A0

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to=C2=A0ntp@ietf.org.=C2=A0

Regards,
Karen and Dieter

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


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




--
Sharon Goldberg
Computer = Science, Boston University
http://www.cs.bu.edu/~goldbe
--001a11449214384730055823882b-- --===============8740740306613449002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============8740740306613449002==-- From nobody Fri Sep 1 09:48: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 27425132E7D; Fri, 1 Sep 2017 09:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 6yGAhlNJnErX; Fri, 1 Sep 2017 09:48:37 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 CA743132DF7; Fri, 1 Sep 2017 09:48:36 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 81so4657691ioj.5; Fri, 01 Sep 2017 09:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WH8zt5ZtmL86GY7mS1veKK80ZPW2lthi4Twg9PK0Uuc=; b=KmOPIoXWgzHpYjSKQjM9as0DMnxJ+eckW0Nvzxm3Jlw3K1K2mwJBaNOO2X1J/uOzjb RaHzcYJgJVDkoyd9JtRoXgxyYsilvihIVxayNdUepPkqDvuRwzr8UM56mgkTwaD9mMgG Sh1QExLChgxQAPm7X7OvAkrdl/+V0P+oQUPYTclD2U1xZcyWuqZxKXXU5DJKYwMV3+fH SxNtdkE0ZQQtZSMOMCmAe11NHkk57BC64Fd8w9cDfpoeGObywa0uAJT0+zqmKJiOredk wx7rJSiIZ52DWjjpjtgcogSXImVvJV3IF7EE+ZVrE2UMXqVOGr//xXeuQU4sP8EwypGE e7yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WH8zt5ZtmL86GY7mS1veKK80ZPW2lthi4Twg9PK0Uuc=; b=aMsQUfaYyT9hVS5x7y1JeYyd0T2fqoDsZEDANXls6qFkFRz6i4tI85auYbpmBYK4z0 kS/VR/fVOOYsKFhzXg2DiFtd8GAlkZO0KERrdDkR1/+ocR9zXXYavRkfkzVBZVAtWMXr z+3z07xISGR+Hi3ITnt2usLK1o2HV2hp4IMYwAEN8VZS1EuLjztvzbXc12++S2Plo1t+ QqYQ+8JjptBq9/8Tm6m3L8nerxUxhkXaDc/LgT3g/PeJuQ32THRcHiBcO7XDx2nMrxBg Jp8O/fjQYrz51oVB2KwpbEhX8zX3MjI3SKNXgbRtj+v7+gspUMV3j467ZiKZGM3DRajZ X3Dg== X-Gm-Message-State: AHPjjUipkfJMOOxqCs7XUEkHhIT9u15eQ65qG9Hli1UL4N17mo2U7sgN o2MQzgZz9oHmgLrqitNaDZSgORqqCQ== X-Google-Smtp-Source: ADKCNb5AD6mY57H+5+EeH28R4ylm3ifr2HycbOwQYAI4WwwKoL+95PBm0p4lvBOL5/IpcQJbVxMHT3pYqMX6AEozO/4= X-Received: by 10.36.3.4 with SMTP id e4mr1365218ite.166.1504284516041; Fri, 01 Sep 2017 09:48:36 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.107.155.195 with HTTP; Fri, 1 Sep 2017 09:47:55 -0700 (PDT) In-Reply-To: References: From: Sharon Goldberg Date: Fri, 1 Sep 2017 12:47:55 -0400 X-Google-Sender-Auth: P_ZLgRin9xj2mw-TmiQ65BxGnQk Message-ID: To: Tal Mizrahi Cc: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: multipart/alternative; boundary="001a11449214384730055823882b" Archived-At: Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-ntp-mac 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: Fri, 01 Sep 2017 16:48:39 -0000 --001a11449214384730055823882b Content-Type: text/plain; charset="UTF-8" Hi Tal, Thanks for your comments. Major comments: > - This may have been discussed before, but still I am not sure what the > answer is: it seems to make sense to define this new MAC as a dedicated > extension field. Any reason not to do that? Since this draft deprecates the > previous MD5-based MAC, there are no backward compatibility considerations. > The draft does not require the use of a new extension field. It works with NTP's legacy MAC fields. As Harlan mentioned earlier, the key ID maps to two items--the key and the algorithm number. We decided not to introduce a new extension field to keep things simple for implementations. > - To allow algorithm agility, I would suggest to add a field that > specifies the algorithm + a corresponding IANA registry. > > This NTP MAC draft only works for the setting of a pre-shared key (PSK) for legacy NTP. For asymmetric keys, we need to use NTS. Given that we are stuck with the PSK model, we can still support algorithm agility by specifying the MAC algorithm as part of the process of configuring the PSK. Specifically, the ntp config file maps the key ID to a secret key and MAC algorithm number. > Less major comments: > - Missing security considerations section. > Yes, will add. > - Missing IANA considerations section. > Given the way we are dealing with algorithm agility, I don't think IANA considerations are relevant. > - "any extension fields that are present" => "every extension fields that > is present". > > Thanks. Sharon > On Wed, Aug 9, 2017 at 7:53 AM, Karen O'Donoghue > wrote: > >> Folks, >> >> This begins a three week working group last call (WGLC) for "Message >> Authentication Code for the Network Time Protocol" >> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ >> >> Please review and provide comments to the mailing list by no later than >> 31 August 2017. Earlier comments and discussion would be appreciated. >> Please note that the chairs will be using this WGLC to determine consensus >> to move this document forward to the IESG. >> >> Also, as a reminder, we have migrated the working group mailing list to >> IETF infrastructure. Please respond to ntp@ietf.org. >> >> Regards, >> Karen and Dieter >> >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >> >> > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a11449214384730055823882b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tal, Thanks for your comments.

Major comments:
- This may ha= ve been discussed before, but still I am not sure what the answer is: it se= ems to make sense to define this new MAC as a dedicated extension field. An= y reason not to do that? Since this draft deprecates the previous MD5-based= MAC, there are no backward compatibility considerations.

The draft does not require the = use of a new extension field. It works with NTP's legacy MAC fields.=C2= =A0 As Harlan mentioned earlier, the key ID maps to two items--the key and = the algorithm number. We decided not to introduce a new extension field to = keep things simple for implementations.
=C2=A0
- To allow algorit= hm agility, I would suggest to add a field that specifies the algorithm + a= corresponding IANA registry.

T= his NTP MAC draft only works for the setting of a pre-shared key (PSK) for = legacy NTP.

For asymmetric keys, we need to u= se NTS.

Given that we are stuck with the PSK = model, we can still support algorithm agility by specifying the MAC algorit= hm as part of the process of configuring the PSK. Specifically, the ntp con= fig file maps the key ID to a secret key and MAC algorithm number.
=C2=A0
Less major comments:
- Missing security considerations sec= tion.

Yes, will add.
<= div>=C2=A0
- Miss= ing IANA considerations section.

Given the way we are dealing with algorithm agility, I don't think IA= NA considerations are relevant.
=C2=A0
- "any extension fields that are p= resent" =3D> "every extension fields that is present".

Thanks.
Sharon


On Wed, Aug 9= , 2017 at 7:53 AM, Karen O'Donoghue <odonoghue@isoc.org> wrote:
Folks,

This begins a three week working group last call (WGLC) for "Message A= uthentication Code for the Network Time Protocol"
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

Please review and provide comments to the mailing list by no later than 31 = August 2017. Earlier comments and discussion would be appreciated. Please n= ote that the chairs will be using this WGLC to determine consensus to move = this document forward to the IESG.=C2=A0

Also, as a reminder, we have migrated the working group mailing list to IET= F infrastructure. Please respond to=C2=A0ntp@ietf.org.=C2=A0

Regards,
Karen and Dieter

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


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




--
Sharon Goldberg
Computer = Science, Boston University
http://www.cs.bu.edu/~goldbe
--001a11449214384730055823882b-- From nobody Fri Sep 1 10:31:21 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 9290A132EB1 for ; Fri, 1 Sep 2017 10:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 R38oU5E9Z0Oo for ; Fri, 1 Sep 2017 10:31:16 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 2212E134154 for ; Fri, 1 Sep 2017 10:31:16 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id a77so3800729qkb.1 for ; Fri, 01 Sep 2017 10:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dC1PqFeqHv2YIVvPif8MYUzt7JOHwbacO3Bc6RbBc1E=; b=GfQTnldAswjnM9tYii9a7RFwy9UgAGkVQCUP9+Dr1BVARwVgz7tSOZB2JZEaQVd++T rItwjgY0fU4tNqytKzSc41ArkrxQxsmXt+6aV9UlqC9wrEgzC2F3ZuT47tZia+IySDyE 698lTqT/KLW208Np1PCCLRRj7yoTVwRhTwK0k= 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=dC1PqFeqHv2YIVvPif8MYUzt7JOHwbacO3Bc6RbBc1E=; b=Vb0JJ8y6ptAj3Mh6rVnRX7FZ7B5qwCSCL0p0mdJ1lhMhB6UjSKJ1gONAeE1aMMcKL4 a768KTvCrGPm5AjOYPaj08EQLcL5eofTEvZ5S2xfHTPP+Z8+fXg8qH9RajiBK+ZPyy5i bHg/gRjUYe+sRB2uXs96Ia24HGSKC5Tpq6VHzn+dL6CrZSFoBUB3h20SMSHiY1bFpwgC cLYPAbVRVYNmBpu2XpMF3QjMdmPZye7LRB+dCCLpuR46JY482WLirtxMDz0duB6Sriho R81K66fi/GD0wzDGgLTqmbAI0Lmo9sFkdJ/9oV3WtQyTKN3ec0pcwSylyLePoKgDy+6T DDGA== X-Gm-Message-State: AHPjjUj4Vzxk7bXMmkqM0LJuyW52wL+SmXOwuh049seABHiIVngz6R1x Pos8JcsqiTe+1316jesqNOaqUEZsvL1s X-Google-Smtp-Source: ADKCNb5qq2b2VBF3KJo3khIcwEio+BuEHLU4T39w9YM1SJUJaW8KarQhg+luuLhS0SWp28lYx/5E4Y72n/AIzEdsq4I= X-Received: by 10.55.79.9 with SMTP id d9mr3408351qkb.179.1504287075042; Fri, 01 Sep 2017 10:31:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 10:31:14 -0700 (PDT) X-Originating-IP: [209.118.251.3] In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Kyle Rose Date: Fri, 1 Sep 2017 13:31:14 -0400 Message-ID: To: Daniel Franke Cc: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 17:31:18 -0000 On Fri, Sep 1, 2017 at 11:25 AM, Daniel Franke wrote: >> (3) Section 5.2 states that key material "SHALL" be extracted >> according to RFC 5705. What is the plan if some TLS 1.3-specific >> mechanism deprecates 5705? > > Current TLS 1.3 drafts swaps the KDF implementation from TLS-PRF for > HKDF but keep the interface exactly the same. The intent, which seems > clear at least to me, is that anything which currently uses RFC 5705 > will use TLS 1.3's exporter to extract keys from TLS 1.3 sessions. > Once TLS 1.3 is finalized, we can publish an update to clarify this if > it isn't clear enough already. I think it's worth clarifying this because you don't want one implementation using 5705 and another using HKDF and agreeing on different keys. For some use cases it doesn't matter (server deriving keys that only it knows), but in cases of shared keys we would have a problem. Kyle From ntp-bounces@ietf.org Fri Sep 1 10:31:21 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F216132F42; Fri, 1 Sep 2017 10:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504287081; bh=tZXtL6qPPqANf4Ft3g25f4Vqj6bXAT8VT0DCfQ00jLA=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=eooq+Zbr3Jfoxshg0vNwnKZtcoquB+EkDR3e1DDWPNLxjmiOKmn7/2hEr4XLIh+1m kDxQhLita+liHjuRmTk4gwrltvZ/Ai8J6hdW0tOLKd8SaKVwlfl48Yvf8hOaLZq//H Lkp5lUwtfN5CJShKpLiK/krAw2YsEdM9CR64qBEU= 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 9290A132EB1 for ; Fri, 1 Sep 2017 10:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 R38oU5E9Z0Oo for ; Fri, 1 Sep 2017 10:31:16 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 2212E134154 for ; Fri, 1 Sep 2017 10:31:16 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id a77so3800729qkb.1 for ; Fri, 01 Sep 2017 10:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dC1PqFeqHv2YIVvPif8MYUzt7JOHwbacO3Bc6RbBc1E=; b=GfQTnldAswjnM9tYii9a7RFwy9UgAGkVQCUP9+Dr1BVARwVgz7tSOZB2JZEaQVd++T rItwjgY0fU4tNqytKzSc41ArkrxQxsmXt+6aV9UlqC9wrEgzC2F3ZuT47tZia+IySDyE 698lTqT/KLW208Np1PCCLRRj7yoTVwRhTwK0k= 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=dC1PqFeqHv2YIVvPif8MYUzt7JOHwbacO3Bc6RbBc1E=; b=Vb0JJ8y6ptAj3Mh6rVnRX7FZ7B5qwCSCL0p0mdJ1lhMhB6UjSKJ1gONAeE1aMMcKL4 a768KTvCrGPm5AjOYPaj08EQLcL5eofTEvZ5S2xfHTPP+Z8+fXg8qH9RajiBK+ZPyy5i bHg/gRjUYe+sRB2uXs96Ia24HGSKC5Tpq6VHzn+dL6CrZSFoBUB3h20SMSHiY1bFpwgC cLYPAbVRVYNmBpu2XpMF3QjMdmPZye7LRB+dCCLpuR46JY482WLirtxMDz0duB6Sriho R81K66fi/GD0wzDGgLTqmbAI0Lmo9sFkdJ/9oV3WtQyTKN3ec0pcwSylyLePoKgDy+6T DDGA== X-Gm-Message-State: AHPjjUj4Vzxk7bXMmkqM0LJuyW52wL+SmXOwuh049seABHiIVngz6R1x Pos8JcsqiTe+1316jesqNOaqUEZsvL1s X-Google-Smtp-Source: ADKCNb5qq2b2VBF3KJo3khIcwEio+BuEHLU4T39w9YM1SJUJaW8KarQhg+luuLhS0SWp28lYx/5E4Y72n/AIzEdsq4I= X-Received: by 10.55.79.9 with SMTP id d9mr3408351qkb.179.1504287075042; Fri, 01 Sep 2017 10:31:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 10:31:14 -0700 (PDT) X-Originating-IP: [209.118.251.3] In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Kyle Rose Date: Fri, 1 Sep 2017 13:31:14 -0400 Message-ID: To: Daniel Franke Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On Fri, Sep 1, 2017 at 11:25 AM, Daniel Franke wrote: >> (3) Section 5.2 states that key material "SHALL" be extracted >> according to RFC 5705. What is the plan if some TLS 1.3-specific >> mechanism deprecates 5705? > > Current TLS 1.3 drafts swaps the KDF implementation from TLS-PRF for > HKDF but keep the interface exactly the same. The intent, which seems > clear at least to me, is that anything which currently uses RFC 5705 > will use TLS 1.3's exporter to extract keys from TLS 1.3 sessions. > Once TLS 1.3 is finalized, we can publish an update to clarify this if > it isn't clear enough already. I think it's worth clarifying this because you don't want one implementation using 5705 and another using HKDF and agreeing on different keys. For some use cases it doesn't matter (server deriving keys that only it knows), but in cases of shared keys we would have a problem. Kyle _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From ntp-bounces@ietf.org Fri Sep 1 12:01:38 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B111343CC; Fri, 1 Sep 2017 12:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504292498; bh=kNUgNl3XcIwfi5Y2WRiR28GdRHGort01+JgBO+TwHFY=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Wb00Zz3Kk+xDvVBC7FV4U03lfbAc7JUpRRxCQUHkPuOOqTh8MXqBPDiGp64XjPIV5 ZRKNosJ/B54b2EQQCjdXKspmi/c5n0tJasGRnO1t8itOh+2ZIBV3NBBXyT8/My+FYW RnxwCD0Xp5r93S9FZMB8SS658dkiGkdchdBB9Lh4= 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 5657C1343B2; Fri, 1 Sep 2017 12:01:37 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 W7_KaLa6kK6c; Fri, 1 Sep 2017 12:01:35 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 6794D1343E1; Fri, 1 Sep 2017 12:01:15 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id v2so6678548wmf.0; Fri, 01 Sep 2017 12:01:15 -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=5jqY2ysNJXSmg73mFrLUJdNZEjUZS67OWmfRO0xxlGY=; b=CMqIKQwPVjuTMUQelODcgHKr44J4/M9o3rwAPNnwdOX3J02MqRdsYLxPkOSECXGTJT 3fD2nG+REt8XqEvCGhg3/CJ0bbf6A/wkXLuP08XoQBLES3oR5vHPGE/zjw0OgbGcObCl pZ6ZLp+nC8pyucV6b0JP3Wiw1E4/BDpa34nwAvrm6aaU+T8vze2hfDaNoJQ0DnnUI9rq AIAKn+wp/MOpXG2hBubUsQHke7vR09IBknPzHFaMKjmP2TlyX9mgZPPwf1/dhx2tdD+F zMv5l9tRYu6Gs5w82cXHJP8HmIue6nHR0iCZ0Zbsr//GHGIH7LEKFcyHIAcI2F/izVb8 DCFA== 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=5jqY2ysNJXSmg73mFrLUJdNZEjUZS67OWmfRO0xxlGY=; b=asn9vCPEWFP8E56QmYpBGLPosySUF2JYLdRadsEnu6QmoKkwqNO8I8vxDwlLJ2KFAt o8DDAnAI1yk4nz/mtnzV6Oa8rV1rqNwFbURAbbJtiMf7cuHcRtrcDJmtxCMf0R6J+2oE eUwaNgCPYGv/2ANtgmY9c5vBQPAVj2WqtH+0ouaOQRAo/0LESOXchdUbT7jBU0cTqshQ KvlaU/iCJEfGUfFzNfwAboahmN+xVNYxkMtAAkgiG6Pt7JpUC8iqpfqaDg+sJ9VTr8mf 2te8lpHMUUpQB5LECL/LNp3jL0SHAhTzv9Ncml+DKPt4vCTaSSfMKzVOkx8RSxBoKznq 0Rng== X-Gm-Message-State: AHPjjUirwZYw4wkBzRoH2zwdkduSxsulUso8UPrBcRV3H3dL5Lt5TWby Rd/umbrAO57jkbJkTzdgm1dFu1dB+nnKa8U= X-Google-Smtp-Source: ADKCNb6V3Ysk9lmFU1jo3MNmqevRFujFTNU8ZbapSQExT5Wo16YMOTGCQxXUYMjCTtZVCjBR5Y+Q1Bi85EpOv8niTYw= X-Received: by 10.80.159.229 with SMTP id c92mr2533420edf.257.1504292473802; Fri, 01 Sep 2017 12:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 12:01:12 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Daniel Franke Date: Fri, 1 Sep 2017 15:01:12 -0400 Message-ID: To: Kyle Rose Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 9/1/17, Kyle Rose wrote: > I think it's worth clarifying this because you don't want one > implementation using 5705 and another using HKDF and agreeing on > different keys. For some use cases it doesn't matter (server deriving > keys that only it knows), but in cases of shared keys we would have a > problem. Got any idea for how to phrase this without creating a normative reference that blocks us on TLS 1.3 publication? _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Fri Sep 1 12:01:39 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 5657C1343B2; Fri, 1 Sep 2017 12:01:37 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 W7_KaLa6kK6c; Fri, 1 Sep 2017 12:01:35 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 6794D1343E1; Fri, 1 Sep 2017 12:01:15 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id v2so6678548wmf.0; Fri, 01 Sep 2017 12:01:15 -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=5jqY2ysNJXSmg73mFrLUJdNZEjUZS67OWmfRO0xxlGY=; b=CMqIKQwPVjuTMUQelODcgHKr44J4/M9o3rwAPNnwdOX3J02MqRdsYLxPkOSECXGTJT 3fD2nG+REt8XqEvCGhg3/CJ0bbf6A/wkXLuP08XoQBLES3oR5vHPGE/zjw0OgbGcObCl pZ6ZLp+nC8pyucV6b0JP3Wiw1E4/BDpa34nwAvrm6aaU+T8vze2hfDaNoJQ0DnnUI9rq AIAKn+wp/MOpXG2hBubUsQHke7vR09IBknPzHFaMKjmP2TlyX9mgZPPwf1/dhx2tdD+F zMv5l9tRYu6Gs5w82cXHJP8HmIue6nHR0iCZ0Zbsr//GHGIH7LEKFcyHIAcI2F/izVb8 DCFA== 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=5jqY2ysNJXSmg73mFrLUJdNZEjUZS67OWmfRO0xxlGY=; b=asn9vCPEWFP8E56QmYpBGLPosySUF2JYLdRadsEnu6QmoKkwqNO8I8vxDwlLJ2KFAt o8DDAnAI1yk4nz/mtnzV6Oa8rV1rqNwFbURAbbJtiMf7cuHcRtrcDJmtxCMf0R6J+2oE eUwaNgCPYGv/2ANtgmY9c5vBQPAVj2WqtH+0ouaOQRAo/0LESOXchdUbT7jBU0cTqshQ KvlaU/iCJEfGUfFzNfwAboahmN+xVNYxkMtAAkgiG6Pt7JpUC8iqpfqaDg+sJ9VTr8mf 2te8lpHMUUpQB5LECL/LNp3jL0SHAhTzv9Ncml+DKPt4vCTaSSfMKzVOkx8RSxBoKznq 0Rng== X-Gm-Message-State: AHPjjUirwZYw4wkBzRoH2zwdkduSxsulUso8UPrBcRV3H3dL5Lt5TWby Rd/umbrAO57jkbJkTzdgm1dFu1dB+nnKa8U= X-Google-Smtp-Source: ADKCNb6V3Ysk9lmFU1jo3MNmqevRFujFTNU8ZbapSQExT5Wo16YMOTGCQxXUYMjCTtZVCjBR5Y+Q1Bi85EpOv8niTYw= X-Received: by 10.80.159.229 with SMTP id c92mr2533420edf.257.1504292473802; Fri, 01 Sep 2017 12:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 12:01:12 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Daniel Franke Date: Fri, 1 Sep 2017 15:01:12 -0400 Message-ID: To: Kyle Rose Cc: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 19:01:37 -0000 On 9/1/17, Kyle Rose wrote: > I think it's worth clarifying this because you don't want one > implementation using 5705 and another using HKDF and agreeing on > different keys. For some use cases it doesn't matter (server deriving > keys that only it knows), but in cases of shared keys we would have a > problem. Got any idea for how to phrase this without creating a normative reference that blocks us on TLS 1.3 publication? From ntp-bounces@ietf.org Fri Sep 1 12:03:49 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5795134458; Fri, 1 Sep 2017 12:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504292629; bh=0MJ2j8v2qZawoPQl4ZMlu/xHndilF1mZxuXnnprl0BI=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=yrExUWpicL3nyul5Bb5waCoaXRu7A6KgBg1LhTwDIIb6xKhYn75Kueit9qyjlDuoY UyE+UsJ0RMdDMaftTTZwVwFy/16MCA5BJfDTuxO0B8NlnvhdTN1A4uCS7LHQKJo2sJ fnv/n/iy1XVpvcRS+mSZdubgnN5ALa1a7hAZR6hE= 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 6B95613426C; Fri, 1 Sep 2017 12:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 B3iijTR41D1s; Fri, 1 Sep 2017 12:03:46 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B3B1342AD; Fri, 1 Sep 2017 12:03:46 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v81J29uR008422; Fri, 1 Sep 2017 20:03:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=vxDmfHte6aQnMhFzXnvlJdITYngZIt5hKuEVQklvT3I=; b=E10cnqwSa4AQD5VLU5S4kVwmDKE6vNsMI1tm5okoZB1ZnrqWSqDPDVt+R+oUVI0i1x7D 7HrQNrdOlOv8ofSclN730P1ngav4np5pyPYi4zRBUu19asu+OYYMSGT2INvaYda4DbVW Fx+jDXrJf7D+VV+T49x4ndCB6otkqV38fgJJxwVyKtgIjxFlBRFukgqK+nb/NH+4yMe3 TLpO/iRzuZ6laDlNbipkBtRqxJaOKLHcSWmUx70R8jKEh/VD6WQ3Axxv3X4QHIAoV8UK 0c01XFa+g990QI2/UMvtcal+K3wSczcA1wrBmOEM0S8CilwTXSlOGpPZkIWNlNa9tv8R vg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2cpkpb71yr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Sep 2017 20:03:44 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v81J1Vac018002; Fri, 1 Sep 2017 15:03:43 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4aw5r2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 01 Sep 2017 15:03:43 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Sep 2017 14:03:42 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 1 Sep 2017 14:03:42 -0500 From: "Salz, Rich" To: Daniel Franke , Kyle Rose Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKgj5MAgAAP24CAACMIAIAAGSMA//+9o4A= Date: Fri, 1 Sep 2017 19:03:41 +0000 Message-ID: <05ADD314-93A1-4F89-A5BE-2FC27CB8D3B5@akamai.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.255] Content-ID: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709010273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709010274 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" SnVzdCBzYXkgc29tZXRoaW5nIGxpa2UNCglJbXBsZW1lbnRhdGlvbnMgTVVTVCB1c2UgSEtERg0K SSBrbm93IHRoZSB0ZW1wdGF0aW9uIGlzIHRvIHdhbnQgdG8gZ2l2ZSBhIHJhdGlvbmFsZSBidXQg eW91IG5lZWRu4oCZdCBwdXQgdGhhdCBpbiB0aGUgdGV4dC4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbnRwIG1haWxpbmcgbGlzdApudHBAaWV0Zi5v cmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAK From nobody Fri Sep 1 12:03: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 6B95613426C; Fri, 1 Sep 2017 12:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 B3iijTR41D1s; Fri, 1 Sep 2017 12:03:46 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B3B1342AD; Fri, 1 Sep 2017 12:03:46 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v81J29uR008422; Fri, 1 Sep 2017 20:03:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=vxDmfHte6aQnMhFzXnvlJdITYngZIt5hKuEVQklvT3I=; b=E10cnqwSa4AQD5VLU5S4kVwmDKE6vNsMI1tm5okoZB1ZnrqWSqDPDVt+R+oUVI0i1x7D 7HrQNrdOlOv8ofSclN730P1ngav4np5pyPYi4zRBUu19asu+OYYMSGT2INvaYda4DbVW Fx+jDXrJf7D+VV+T49x4ndCB6otkqV38fgJJxwVyKtgIjxFlBRFukgqK+nb/NH+4yMe3 TLpO/iRzuZ6laDlNbipkBtRqxJaOKLHcSWmUx70R8jKEh/VD6WQ3Axxv3X4QHIAoV8UK 0c01XFa+g990QI2/UMvtcal+K3wSczcA1wrBmOEM0S8CilwTXSlOGpPZkIWNlNa9tv8R vg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2cpkpb71yr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Sep 2017 20:03:44 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v81J1Vac018002; Fri, 1 Sep 2017 15:03:43 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ck4aw5r2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 01 Sep 2017 15:03:43 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Sep 2017 14:03:42 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 1 Sep 2017 14:03:42 -0500 From: "Salz, Rich" To: Daniel Franke , Kyle Rose CC: "ntp@ietf.org" , "tictoc@ietf.org" , "Karen O'Donoghue" Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCM2s3Nc34m0O8jzUH1rPjTqKgj5MAgAAP24CAACMIAIAAGSMA//+9o4A= Date: Fri, 1 Sep 2017 19:03:41 +0000 Message-ID: <05ADD314-93A1-4F89-A5BE-2FC27CB8D3B5@akamai.com> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.255] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709010273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-01_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709010274 Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 19:03:47 -0000 SnVzdCBzYXkgc29tZXRoaW5nIGxpa2UNCglJbXBsZW1lbnRhdGlvbnMgTVVTVCB1c2UgSEtERg0K SSBrbm93IHRoZSB0ZW1wdGF0aW9uIGlzIHRvIHdhbnQgdG8gZ2l2ZSBhIHJhdGlvbmFsZSBidXQg eW91IG5lZWRu4oCZdCBwdXQgdGhhdCBpbiB0aGUgdGV4dC4NCg0K From ntp-bounces@ietf.org Fri Sep 1 12:14:53 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B48134522; Fri, 1 Sep 2017 12:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504293293; bh=4Rtvhnm7oF6unZ7w02WeXz6ZKR5q0iyaofQEY64pLPI=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Njv0aNWE5wOykvbXVpxLxPRlob20l3d0q2CFdbQn/cp0cC2aByncSs/BIFouiewr1 TK1uzHzyKzoe2FdXiwYWedDiF+KRqp7nRRGN/2MMplPbfMxQw1OB/mI4PClaYpIsbw PgmmmqhUE65C+/itE2f16B9XAFGERqSqHwgnCFuA= 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 8829E13450E; Fri, 1 Sep 2017 12:14:50 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 QFuwpLbIyOs5; Fri, 1 Sep 2017 12:14:49 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 20CA21344DE; Fri, 1 Sep 2017 12:14:49 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 187so6650060wmn.1; Fri, 01 Sep 2017 12:14: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=w7RPT0rhtg0aTp5TdqfRrCTycFb8+JZ7HQLqdqjfeWA=; b=oSACf8umyGC+qP5u7wzUiHt6poZ7vOggkedke4SIz7uQH0Oou/mu0kzDrF6BIgjZRz OL2lYVCCtoyHaDM0cX5janp5YQPTx+gILxiiKKaFF8bLPMvGHvxWPWGR2dtD8NNu08UH GS6rps5gRGYi/S5UH60Owa8xC1U9XBVdl3RTRNRkmZumw7Wi9JeATyTNqnoCVhCwtC+i PyFdXpbgvwp2JrVcOq3vRiH0h9lCesCIxGnbjvX/StExMZ2cAugbWtVC4bWb9HFdj2yN bprJMNqGstWyeahsnKfGw9Cv9vVo6JwXW7n1WgcmFyFrC163+haGnqqlXw0APdYZ24dq 9hTQ== 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=w7RPT0rhtg0aTp5TdqfRrCTycFb8+JZ7HQLqdqjfeWA=; b=I+oGI7rDfDru6ErpO/2fhsUshizJIg4nuFZecmds/NsCYhMUJUwT3rdqQGNyePAzwc KSI9uKzwf0peO2XoIlVtIe6RgPPjDOqiEcuRVJsyJtf1XkNNmV9sjGz1VjF37oEw2NcB h9Igm67O9/PZuKBkB6/ACw4hpq+/DIXX/fYW1dE/lojNfO2amEFIymsc+UO+BUIKL+hj VmhgmwLLEzxtgYfN+3zEt+P9r22xoEKn9t3HFRf342HMJiSdrnjz37PfKHRWm5vcGcTI JKiInIDo2qCxvM+39yrwurCdBzGJi5c2dAco6TI4DH1ENe4rFsqvO7k8aF9cYg0WXI7K LLxg== X-Gm-Message-State: AHPjjUjcUge6fkdX9Vo8L4xXgEJxoFNcodzUEfX18cwaYIvwJJMvRpAa y/5J6nUnhPxpnMA7hjWqxaBCKX9hlA== X-Google-Smtp-Source: ADKCNb6isvl5LoyxgZie33nqZ5kPVevw6hRgUZzgx9cT+8DZdYN7vxjtNu3ReD0UzqKjukBvgt7XnsbVIYjteQ/GR78= X-Received: by 10.80.215.88 with SMTP id i24mr2567503edj.278.1504293287530; Fri, 01 Sep 2017 12:14:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 12:14:46 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Daniel Franke Date: Fri, 1 Sep 2017 15:14:46 -0400 Message-ID: To: Kyle Rose Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 9/1/17, Daniel Franke wrote: > Got any idea for how to phrase this without creating a normative > reference that blocks us on TLS 1.3 publication? So actually, I just took another close look at 5705 and at the history of the TLS RFCs, and I think the Right Thing is already unambiguous. RFC 5705 says to apply "TLS Pseudorandom Function in use for the session". The TLS PRF has already changed incompatibly in past TLS versions. In TLS 1.2, it's part of the ciphersuite's specification. In 1.1 and prior, it was fixed, and based on an XOR of MD5 and SHA1. So any correct RFC 5705 implementation is already taking protocol version into account and choosing what function to apply accordingly. _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Fri Sep 1 12:14: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 8829E13450E; Fri, 1 Sep 2017 12:14:50 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 QFuwpLbIyOs5; Fri, 1 Sep 2017 12:14:49 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 20CA21344DE; Fri, 1 Sep 2017 12:14:49 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 187so6650060wmn.1; Fri, 01 Sep 2017 12:14: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=w7RPT0rhtg0aTp5TdqfRrCTycFb8+JZ7HQLqdqjfeWA=; b=oSACf8umyGC+qP5u7wzUiHt6poZ7vOggkedke4SIz7uQH0Oou/mu0kzDrF6BIgjZRz OL2lYVCCtoyHaDM0cX5janp5YQPTx+gILxiiKKaFF8bLPMvGHvxWPWGR2dtD8NNu08UH GS6rps5gRGYi/S5UH60Owa8xC1U9XBVdl3RTRNRkmZumw7Wi9JeATyTNqnoCVhCwtC+i PyFdXpbgvwp2JrVcOq3vRiH0h9lCesCIxGnbjvX/StExMZ2cAugbWtVC4bWb9HFdj2yN bprJMNqGstWyeahsnKfGw9Cv9vVo6JwXW7n1WgcmFyFrC163+haGnqqlXw0APdYZ24dq 9hTQ== 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=w7RPT0rhtg0aTp5TdqfRrCTycFb8+JZ7HQLqdqjfeWA=; b=I+oGI7rDfDru6ErpO/2fhsUshizJIg4nuFZecmds/NsCYhMUJUwT3rdqQGNyePAzwc KSI9uKzwf0peO2XoIlVtIe6RgPPjDOqiEcuRVJsyJtf1XkNNmV9sjGz1VjF37oEw2NcB h9Igm67O9/PZuKBkB6/ACw4hpq+/DIXX/fYW1dE/lojNfO2amEFIymsc+UO+BUIKL+hj VmhgmwLLEzxtgYfN+3zEt+P9r22xoEKn9t3HFRf342HMJiSdrnjz37PfKHRWm5vcGcTI JKiInIDo2qCxvM+39yrwurCdBzGJi5c2dAco6TI4DH1ENe4rFsqvO7k8aF9cYg0WXI7K LLxg== X-Gm-Message-State: AHPjjUjcUge6fkdX9Vo8L4xXgEJxoFNcodzUEfX18cwaYIvwJJMvRpAa y/5J6nUnhPxpnMA7hjWqxaBCKX9hlA== X-Google-Smtp-Source: ADKCNb6isvl5LoyxgZie33nqZ5kPVevw6hRgUZzgx9cT+8DZdYN7vxjtNu3ReD0UzqKjukBvgt7XnsbVIYjteQ/GR78= X-Received: by 10.80.215.88 with SMTP id i24mr2567503edj.278.1504293287530; Fri, 01 Sep 2017 12:14:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 12:14:46 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Daniel Franke Date: Fri, 1 Sep 2017 15:14:46 -0400 Message-ID: To: Kyle Rose Cc: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 19:14:50 -0000 On 9/1/17, Daniel Franke wrote: > Got any idea for how to phrase this without creating a normative > reference that blocks us on TLS 1.3 publication? So actually, I just took another close look at 5705 and at the history of the TLS RFCs, and I think the Right Thing is already unambiguous. RFC 5705 says to apply "TLS Pseudorandom Function in use for the session". The TLS PRF has already changed incompatibly in past TLS versions. In TLS 1.2, it's part of the ciphersuite's specification. In 1.1 and prior, it was fixed, and based on an XOR of MD5 and SHA1. So any correct RFC 5705 implementation is already taking protocol version into account and choosing what function to apply accordingly. From ntp-bounces@ietf.org Fri Sep 1 12:24:58 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3B8134526; Fri, 1 Sep 2017 12:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504293898; bh=jegP5kAOU/gPt3NTfS3Y5voIldFIk8mv9JkTBVFAxpk=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=qal+8SKbkI3d3jdF9wJbXzZvZbLKWFrpv48reS8MSMBqBcKY2/n+NDp81x9bS8hlP qz+eCHGn8D8QWnEf6cfKKSdT60nWDArBX7yv+IcwHabjOKEzrv+l0yR4ggWMGMwtOH XAB0Po/EdzrnQ+c+1FQQh7tY4mc9iM1mcMmV/ezU= 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 BB2BF1342BD for ; Fri, 1 Sep 2017 12:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 Eq6-DF9ANAL1 for ; Fri, 1 Sep 2017 12:24:54 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 0743E1321C7 for ; Fri, 1 Sep 2017 12:24:54 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id w42so5077313qtg.5 for ; Fri, 01 Sep 2017 12:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TUAPgKGKsTI2AY6c/43W+8iN3niG0/6oic3noyrieeg=; b=UCdVm417HqVA72RTxHm/ppewyOApjjOkVYnOYunKWMrNqv7IOq6vYjD73sSyZLB1Qb ox1yT3HSn7Y0Wx3Qq2eeQ9LlxKjTeBV1Hsg3ovU0j0+5Yyb3G839e96p+sBkqL3jFo7p A9/ODnEybZY4/M2ZgTgx71lhvwYkF4rf+nE/s= 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=TUAPgKGKsTI2AY6c/43W+8iN3niG0/6oic3noyrieeg=; b=uPW2rTftTz2YHSvPmE/ijSLL7KEJGOnZBI3Z4WMqNuHb28HMLtYBW6zRq+JRcUdnk8 PKjERKOw++CsCPzXG8hrDJY8JForMabTclT6ZP+iexUa2LIcubkcTBg8PlShsONYWD1X k2jYqMFgpblF0JfZeohNqQ4AGSFpRB9SgUIHSb0coeOkK3iGBFC9c44oOfZ90lNjDqw4 8mophonQ0jPmv7EqYJv7udvFRtepx1mmE4vOdCNXwjS6vLuDPXhgM1WAkOYeuRzxNVf+ 0rgFCf/qVLl268qGZqkjD7Uk82ts7/xTmBsMe6VzpXuCqXVTtt1qb0VYPgkec32VraYE skUw== X-Gm-Message-State: AHPjjUh6KbldztuQ8TnNGOJxcZVmznIdqlS99tAbuHBlc+kNKOcnLiKe BxwtMZf6rKK2ycu6ElM/QNv9/ZJ+h6GD X-Google-Smtp-Source: ADKCNb6MXmW61lhqXqKUYUxHWfJjwF6Hw+2/FFFEPAATkV4xBJY6fnSGCfH9lzegfqZ6gNyBvZtfU+xfp+dF8V/IVeU= X-Received: by 10.237.48.3 with SMTP id 3mr4112703qte.300.1504293892935; Fri, 01 Sep 2017 12:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 12:24:51 -0700 (PDT) X-Originating-IP: [2607:fb90:12d2:8a15:9435:57ab:1a9e:d881] Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 12:24:51 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Kyle Rose Date: Fri, 1 Sep 2017 15:24:51 -0400 Message-ID: To: Daniel Franke Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: , Cc: "ntp@ietf.org" , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: multipart/mixed; boundary="===============0346996808754386309==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============0346996808754386309== Content-Type: multipart/alternative; boundary="94eb2c0cb840206759055825b716" --94eb2c0cb840206759055825b716 Content-Type: text/plain; charset="UTF-8" On Sep 1, 2017 3:14 PM, "Daniel Franke" wrote: So actually, I just took another close look at 5705 and at the history of the TLS RFCs, and I think the Right Thing is already unambiguous. RFC 5705 says to apply "TLS Pseudorandom Function in use for the session". The TLS PRF has already changed incompatibly in past TLS versions. In TLS 1.2, it's part of the ciphersuite's specification. In 1.1 and prior, it was fixed, and based on an XOR of MD5 and SHA1. So any correct RFC 5705 implementation is already taking protocol version into account and choosing what function to apply accordingly. Ok, I'm satisfied. I just checked the relevant text in the TLS 1.3 draft, and it looks like it would be unambiguous here: q( [RFC5705] defines keying material exporters for TLS in terms of the TLS pseudorandom function (PRF). This document replaces the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same. ) Kyle --94eb2c0cb840206759055825b716 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sep 1, 2017 3:14 PM, "Daniel Franke" <dfoxfranke@gmail.com> wrote:

So actually, I just took another close look at 5705 and at the histor= y
of the TLS RFCs, and I think the Right Thing is already unambiguous.
RFC 5705 says to apply "TLS Pseudorandom Function in use for the
session". The TLS PRF has already changed incompatibly in past TLS
versions. In TLS 1.2, it's part of the ciphersuite's specification.= In
1.1 and prior, it was fixed, and based on an XOR of MD5 and SHA1. So
any correct RFC 5705 implementation is already taking protocol version
into account and choosing what function to apply accordingly.

Ok, I= 9;m satisfied. I just checked the relevant text in the TLS 1.3 draft, and i= t looks like it would be unambiguous here:

q(=C2=A0[RFC5705] defines keying material exporters for = TLS in terms of the TLS pseudorandom function (PRF). This document replaces= the PRF with HKDF, thus requiring a new construction. The exporter interfa= ce remains the same. )

K= yle

--94eb2c0cb840206759055825b716-- --===============0346996808754386309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============0346996808754386309==-- From nobody Fri Sep 1 12:25:03 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 BB2BF1342BD for ; Fri, 1 Sep 2017 12:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 Eq6-DF9ANAL1 for ; Fri, 1 Sep 2017 12:24:54 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 0743E1321C7 for ; Fri, 1 Sep 2017 12:24:54 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id w42so5077313qtg.5 for ; Fri, 01 Sep 2017 12:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TUAPgKGKsTI2AY6c/43W+8iN3niG0/6oic3noyrieeg=; b=UCdVm417HqVA72RTxHm/ppewyOApjjOkVYnOYunKWMrNqv7IOq6vYjD73sSyZLB1Qb ox1yT3HSn7Y0Wx3Qq2eeQ9LlxKjTeBV1Hsg3ovU0j0+5Yyb3G839e96p+sBkqL3jFo7p A9/ODnEybZY4/M2ZgTgx71lhvwYkF4rf+nE/s= 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=TUAPgKGKsTI2AY6c/43W+8iN3niG0/6oic3noyrieeg=; b=uPW2rTftTz2YHSvPmE/ijSLL7KEJGOnZBI3Z4WMqNuHb28HMLtYBW6zRq+JRcUdnk8 PKjERKOw++CsCPzXG8hrDJY8JForMabTclT6ZP+iexUa2LIcubkcTBg8PlShsONYWD1X k2jYqMFgpblF0JfZeohNqQ4AGSFpRB9SgUIHSb0coeOkK3iGBFC9c44oOfZ90lNjDqw4 8mophonQ0jPmv7EqYJv7udvFRtepx1mmE4vOdCNXwjS6vLuDPXhgM1WAkOYeuRzxNVf+ 0rgFCf/qVLl268qGZqkjD7Uk82ts7/xTmBsMe6VzpXuCqXVTtt1qb0VYPgkec32VraYE skUw== X-Gm-Message-State: AHPjjUh6KbldztuQ8TnNGOJxcZVmznIdqlS99tAbuHBlc+kNKOcnLiKe BxwtMZf6rKK2ycu6ElM/QNv9/ZJ+h6GD X-Google-Smtp-Source: ADKCNb6MXmW61lhqXqKUYUxHWfJjwF6Hw+2/FFFEPAATkV4xBJY6fnSGCfH9lzegfqZ6gNyBvZtfU+xfp+dF8V/IVeU= X-Received: by 10.237.48.3 with SMTP id 3mr4112703qte.300.1504293892935; Fri, 01 Sep 2017 12:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 12:24:51 -0700 (PDT) X-Originating-IP: [2607:fb90:12d2:8a15:9435:57ab:1a9e:d881] Received: by 10.12.176.13 with HTTP; Fri, 1 Sep 2017 12:24:51 -0700 (PDT) In-Reply-To: References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> From: Kyle Rose Date: Fri, 1 Sep 2017 15:24:51 -0400 Message-ID: To: Daniel Franke Cc: "Karen O'Donoghue" , "ntp@ietf.org" , "tictoc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0cb840206759055825b716" Archived-At: Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp 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: Fri, 01 Sep 2017 19:24:57 -0000 --94eb2c0cb840206759055825b716 Content-Type: text/plain; charset="UTF-8" On Sep 1, 2017 3:14 PM, "Daniel Franke" wrote: So actually, I just took another close look at 5705 and at the history of the TLS RFCs, and I think the Right Thing is already unambiguous. RFC 5705 says to apply "TLS Pseudorandom Function in use for the session". The TLS PRF has already changed incompatibly in past TLS versions. In TLS 1.2, it's part of the ciphersuite's specification. In 1.1 and prior, it was fixed, and based on an XOR of MD5 and SHA1. So any correct RFC 5705 implementation is already taking protocol version into account and choosing what function to apply accordingly. Ok, I'm satisfied. I just checked the relevant text in the TLS 1.3 draft, and it looks like it would be unambiguous here: q( [RFC5705] defines keying material exporters for TLS in terms of the TLS pseudorandom function (PRF). This document replaces the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same. ) Kyle --94eb2c0cb840206759055825b716 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sep 1, 2017 3:14 PM, "Daniel Franke" <dfoxfranke@gmail.com> wrote:

So actually, I just took another close look at 5705 and at the histor= y
of the TLS RFCs, and I think the Right Thing is already unambiguous.
RFC 5705 says to apply "TLS Pseudorandom Function in use for the
session". The TLS PRF has already changed incompatibly in past TLS
versions. In TLS 1.2, it's part of the ciphersuite's specification.= In
1.1 and prior, it was fixed, and based on an XOR of MD5 and SHA1. So
any correct RFC 5705 implementation is already taking protocol version
into account and choosing what function to apply accordingly.

Ok, I= 9;m satisfied. I just checked the relevant text in the TLS 1.3 draft, and i= t looks like it would be unambiguous here:

q(=C2=A0[RFC5705] defines keying material exporters for = TLS in terms of the TLS pseudorandom function (PRF). This document replaces= the PRF with HKDF, thus requiring a new construction. The exporter interfa= ce remains the same. )

K= yle

--94eb2c0cb840206759055825b716-- From ntp-bounces@ietf.org Fri Sep 1 13:23:39 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4585B1344DF; Fri, 1 Sep 2017 13:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504297419; bh=x89XusHWYOyNfVT4Hh0+SJ2P5d+3tcRPqrTTF79q/sc=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=VEvf/n/ac4z6eji/tgei4hIjzvhwYl8sOiHqMuzMz5VIpNLU/N2PBglkUgSo44ry3 pbyozVQKJ49z7j9D7WHee2UCSlr64CjLZpWGdGwmh2a/VghqGyILwGD53wVXoeczam RezIJCO+lCmDYTRichh5hNhIFTWVxCT62RAQc+Wo= 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 3C28B1270AB; Fri, 1 Sep 2017 13:23:36 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 xnXcpUDSCrmQ; Fri, 1 Sep 2017 13:23:31 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 74E901342E3; Fri, 1 Sep 2017 13:23:20 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id r202so2846488wmd.0; Fri, 01 Sep 2017 13:23:20 -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=UkWds0k6vsap2HLKRfuB0xV8j6wweesZDM9UbP3VahY=; b=vFcwv+tBwNmhSKMjzy8XnCHAObHD5NywEbYt6+R7TfN7uIhVt18DbtFK4jsSMo4d+7 G3b43rh6LX6dmHOlAq4+dqdnZOwp4Et/G3HXJ05XSiPcoHX3ID+V5G3sfnH2ku7yalHO SUdBytY4DzwAKbcId4Ppws7Lj4CxKszhry4fhAOAjUZM0HGC8p0A/LdzitS0XB8Fx7xH jLe9xGRBSyB/86YybrDo5uwcRZCuzvnrvlFhUt6YjSwPBKDCOW+dh9Z+YmbT8R66hke+ L+dqerzoYFpE/ok5LiFkEy/humPwAstbTgj5L/yjlwbjMPTy7BZPx4yTPEgcr0F6+GLl FNOg== 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=UkWds0k6vsap2HLKRfuB0xV8j6wweesZDM9UbP3VahY=; b=osrMDI4Q80tRu6D6C+lze7FeyP+kKqbimSW26uP0rBm84uHvkodDaEKBl0NLeUnWYz yCR/uvH7nN4u1w+iq48L0SDtoCErD4YaLuhZq/vC6vQ5mT98hhwf3uY5PQ/jNEUFFQOX EDU/5IHPPtQF7myGUBtZrmSHfOzjZpoNVgIynT/W04MMek/vUzweVxxAtiRWmUZkEo6W QjM+lUW/PNfHMh3WhtAvIJ/dm1hb4TX83AEebTZ+5NCwZGxXL29ljTW3RuT2mbVoT40d f+cgHwaqiPXmPMZNZZDPz+HJqfN9JRXvpO0+QHj1iNM15sojXoD53tG0cI24TgVm3sMr B/vg== X-Gm-Message-State: AHPjjUjiURi7C3Kze8QsU+P59UMDjFJ8hTjB9HaX3Pn+UtCEkNksTssN kGqCYxvD22OMJpGlZmX35977WfHhpQ== X-Google-Smtp-Source: ADKCNb4uACUrScjYmo+UPXfoJxg+e5l06G+rbVbSznJ8Lu2hdW9afxAn2EKCc3t6H6zxbWkJmpi4f5+90qdgUGBj9Xo= X-Received: by 10.80.215.29 with SMTP id t29mr2569510edi.141.1504297398792; Fri, 01 Sep 2017 13:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 13:23:18 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Fri, 1 Sep 2017 16:23:18 -0400 Message-ID: To: Sharon Goldberg Archived-At: Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-ntp-mac 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: , Cc: "ntp@ietf.org" , Tal Mizrahi , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntp-bounces@ietf.org Sender: "ntp" On 9/1/17, Sharon Goldberg wrote: >> Less major comments: >> - Missing security considerations section. > > Yes, will add. Oif, how'd I overlook that until now? Everything that needs discussion is already discussed IMO, you just need to move it into a section with the required title. >> - Missing IANA considerations section. >> > > Given the way we are dealing with algorithm agility, I don't think IANA > considerations are relevant. By policy, the IETF requires the section to be present when it's submitted to the IESG, but it can be empty, like so: 8. IANA Considerations None. [RFC EDITOR: please remove this section before publication] _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp From nobody Fri Sep 1 13:23:43 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 3C28B1270AB; Fri, 1 Sep 2017 13:23:36 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 xnXcpUDSCrmQ; Fri, 1 Sep 2017 13:23:31 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 74E901342E3; Fri, 1 Sep 2017 13:23:20 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id r202so2846488wmd.0; Fri, 01 Sep 2017 13:23:20 -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=UkWds0k6vsap2HLKRfuB0xV8j6wweesZDM9UbP3VahY=; b=vFcwv+tBwNmhSKMjzy8XnCHAObHD5NywEbYt6+R7TfN7uIhVt18DbtFK4jsSMo4d+7 G3b43rh6LX6dmHOlAq4+dqdnZOwp4Et/G3HXJ05XSiPcoHX3ID+V5G3sfnH2ku7yalHO SUdBytY4DzwAKbcId4Ppws7Lj4CxKszhry4fhAOAjUZM0HGC8p0A/LdzitS0XB8Fx7xH jLe9xGRBSyB/86YybrDo5uwcRZCuzvnrvlFhUt6YjSwPBKDCOW+dh9Z+YmbT8R66hke+ L+dqerzoYFpE/ok5LiFkEy/humPwAstbTgj5L/yjlwbjMPTy7BZPx4yTPEgcr0F6+GLl FNOg== 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=UkWds0k6vsap2HLKRfuB0xV8j6wweesZDM9UbP3VahY=; b=osrMDI4Q80tRu6D6C+lze7FeyP+kKqbimSW26uP0rBm84uHvkodDaEKBl0NLeUnWYz yCR/uvH7nN4u1w+iq48L0SDtoCErD4YaLuhZq/vC6vQ5mT98hhwf3uY5PQ/jNEUFFQOX EDU/5IHPPtQF7myGUBtZrmSHfOzjZpoNVgIynT/W04MMek/vUzweVxxAtiRWmUZkEo6W QjM+lUW/PNfHMh3WhtAvIJ/dm1hb4TX83AEebTZ+5NCwZGxXL29ljTW3RuT2mbVoT40d f+cgHwaqiPXmPMZNZZDPz+HJqfN9JRXvpO0+QHj1iNM15sojXoD53tG0cI24TgVm3sMr B/vg== X-Gm-Message-State: AHPjjUjiURi7C3Kze8QsU+P59UMDjFJ8hTjB9HaX3Pn+UtCEkNksTssN kGqCYxvD22OMJpGlZmX35977WfHhpQ== X-Google-Smtp-Source: ADKCNb4uACUrScjYmo+UPXfoJxg+e5l06G+rbVbSznJ8Lu2hdW9afxAn2EKCc3t6H6zxbWkJmpi4f5+90qdgUGBj9Xo= X-Received: by 10.80.215.29 with SMTP id t29mr2569510edi.141.1504297398792; Fri, 01 Sep 2017 13:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.157.140 with HTTP; Fri, 1 Sep 2017 13:23:18 -0700 (PDT) In-Reply-To: References: From: Daniel Franke Date: Fri, 1 Sep 2017 16:23:18 -0400 Message-ID: To: Sharon Goldberg Cc: Tal Mizrahi , "ntp@ietf.org" , "tictoc@ietf.org" , "Karen O'Donoghue" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-ntp-mac 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: Fri, 01 Sep 2017 20:23:36 -0000 On 9/1/17, Sharon Goldberg wrote: >> Less major comments: >> - Missing security considerations section. > > Yes, will add. Oif, how'd I overlook that until now? Everything that needs discussion is already discussed IMO, you just need to move it into a section with the required title. >> - Missing IANA considerations section. >> > > Given the way we are dealing with algorithm agility, I don't think IANA > considerations are relevant. By policy, the IETF requires the section to be present when it's submitted to the IESG, but it can be empty, like so: 8. IANA Considerations None. [RFC EDITOR: please remove this section before publication] From ntp-bounces@ietf.org Fri Sep 1 13:30:02 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BB133089; Fri, 1 Sep 2017 13:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504297802; bh=uBXmxybdl98dX9puJeSBeZquHKWJnN4QR+KuYo40Rt4=; h=In-Reply-To:References:From:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=teElZfw7tuY7zmTK0k3GrSn1SGTusnKOIXvxEVZdW3DPozKot6FqrRrHwjrrNa9c/ DsxGKu57ejosmHGpdbvu9c0onYfF3K/PtwIzJVSkBWZPMawS4VviMDJDcnxpM2q6hz lO0gP7hODc32gJc3CX63SM0QDo0dVT1ZXTbLQfQA= 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 3405313219E; Fri, 1 Sep 2017 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 zIiMcYdpulfz; Fri, 1 Sep 2017 13:29:58 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 AC846133089; Fri, 1 Sep 2017 13:29:58 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id f199so658156ita.1; Fri, 01 Sep 2017 13:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=T7s3z7TcW95F+HQtZvPyWk6042eyByA46TYhlHQUelU=; b=rMwH6Qw+Nn2HOhd1U5Z8uKl8hCL9UWY5RAFX2I8Jvzzh7Dyfqe+0nXyjZaYLLorG5a 7NEsp8VGN398iBfzdOhZXS2Szdro/lRACBTIL1GT0x9zvUWlvKxPLhuVmZYXJ3Erni+j zDLcpMoA5RMTnIbiiHyuaxpsFRZECRCuRcNPjXvY1HYLhhOoYRLU609pT4RJLDeyvTei DtxDxyjPSHZncP0Vs7KgLU69CVy/T2exN37JnbOg6L5OmxFMxrHke5QJIt/Zzl61bU+e A7xW3pr9wfxGK8J7Dtx+hjGZW9I0AgP01wM62dM0IAA4DB/9LKdbuFZNrC1MIQcZMS3l BPjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=T7s3z7TcW95F+HQtZvPyWk6042eyByA46TYhlHQUelU=; b=RHS8ZEPHkXXc65GrPNns+SaP+cQ9hVIYBMUZ8GRZvVajWSqmT6UcWNTpfR/TXLRt6z flDsvIy+6g1hWfOXu3I234miiNjfRjnpPljKvc9gGqnYf5LfYanHiUjjXK5X+dLv82JP flHwDNs+tnJstgT9Y3PnJgcj19pC1qn/F62dRe/LhfWaY05iq50z7jVXSgLYMpWORaZF Kp8NiSSwuaW8psNuMQKM+zItBAennIO2sjx7kAYm7oxEXQdz7eyCohKvL96/YQqVjJ4S 7GIvnWNx7sVYLdYAES7f9gII/alSkuXXwVRK92JsZRjLDbfjy8pfaDuWzyhF0DMpp2/R ILhw== X-Gm-Message-State: AHPjjUjxQPy1ruCL1Ja3f9WnKjfBSxLV7bJiRFMXV+X29sVsgFADUHnF Q54ztijdcajGoeaLC0nZu4p/RyDIGA== X-Google-Smtp-Source: ADKCNb5XuhAuI4vKU1r7IVhz6nDZp/2xo8e5wyip7EAWuZ5UDsSNF8feWjT4tVG/Gz3meapGU8PtH0nFf0elJW3LVno= X-Received: by 10.36.82.148 with SMTP id d142mr645788itb.127.1504297797978; Fri, 01 Sep 2017 13:29:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.155.195 with HTTP; Fri, 1 Sep 2017 13:29:17 -0700 (PDT) In-Reply-To: References: From: Sharon Goldberg Date: Fri, 1 Sep 2017 16:29:17 -0400 X-Google-Sender-Auth: aZlYk9rjWzE7wOEeYv6jwGs6-lo Message-ID: To: Daniel Franke Archived-At: Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-ntp-mac 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: , Cc: "ntp@ietf.org" , Tal Mizrahi , "tictoc@ietf.org" , Karen O'Donoghue Content-Type: multipart/mixed; boundary="===============2982330170228391769==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============2982330170228391769== Content-Type: multipart/alternative; boundary="001a11448fa2e28fb60558269fc0" --001a11448fa2e28fb60558269fc0 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 1, 2017 at 4:23 PM, Daniel Franke wrote: > On 9/1/17, Sharon Goldberg wrote: > >> Less major comments: > >> - Missing security considerations section. > > > > Yes, will add. > > Oif, how'd I overlook that until now? Everything that needs discussion > is already discussed IMO, you just need to move it into a section with > the required title. > > Yes, that happened to me too :) Will do. Sharon --001a11448fa2e28fb60558269fc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 1, 2017 at 4:23 PM, Daniel Franke <dfoxfranke@gmail.com>= wrote:
On 9/1/17, Sharon Go= ldberg <goldbe@cs.= bu.edu> wrote:
>> Less major comments:
>> - Missing security considerations section.
>
> Yes, will add.

Oif, how'd I overlook that until now? Everything that needs disc= ussion
is already discussed IMO, you just need to move it into a section with
the required title.

Yes, that happened to me too :)=C2=A0 Wi= ll do.
=C2=A0
Sharon
--001a11448fa2e28fb60558269fc0-- --===============2982330170228391769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============2982330170228391769==-- From nobody Fri Sep 1 13:30:02 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 3405313219E; Fri, 1 Sep 2017 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 zIiMcYdpulfz; Fri, 1 Sep 2017 13:29:58 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 AC846133089; Fri, 1 Sep 2017 13:29:58 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id f199so658156ita.1; Fri, 01 Sep 2017 13:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=T7s3z7TcW95F+HQtZvPyWk6042eyByA46TYhlHQUelU=; b=rMwH6Qw+Nn2HOhd1U5Z8uKl8hCL9UWY5RAFX2I8Jvzzh7Dyfqe+0nXyjZaYLLorG5a 7NEsp8VGN398iBfzdOhZXS2Szdro/lRACBTIL1GT0x9zvUWlvKxPLhuVmZYXJ3Erni+j zDLcpMoA5RMTnIbiiHyuaxpsFRZECRCuRcNPjXvY1HYLhhOoYRLU609pT4RJLDeyvTei DtxDxyjPSHZncP0Vs7KgLU69CVy/T2exN37JnbOg6L5OmxFMxrHke5QJIt/Zzl61bU+e A7xW3pr9wfxGK8J7Dtx+hjGZW9I0AgP01wM62dM0IAA4DB/9LKdbuFZNrC1MIQcZMS3l BPjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=T7s3z7TcW95F+HQtZvPyWk6042eyByA46TYhlHQUelU=; b=RHS8ZEPHkXXc65GrPNns+SaP+cQ9hVIYBMUZ8GRZvVajWSqmT6UcWNTpfR/TXLRt6z flDsvIy+6g1hWfOXu3I234miiNjfRjnpPljKvc9gGqnYf5LfYanHiUjjXK5X+dLv82JP flHwDNs+tnJstgT9Y3PnJgcj19pC1qn/F62dRe/LhfWaY05iq50z7jVXSgLYMpWORaZF Kp8NiSSwuaW8psNuMQKM+zItBAennIO2sjx7kAYm7oxEXQdz7eyCohKvL96/YQqVjJ4S 7GIvnWNx7sVYLdYAES7f9gII/alSkuXXwVRK92JsZRjLDbfjy8pfaDuWzyhF0DMpp2/R ILhw== X-Gm-Message-State: AHPjjUjxQPy1ruCL1Ja3f9WnKjfBSxLV7bJiRFMXV+X29sVsgFADUHnF Q54ztijdcajGoeaLC0nZu4p/RyDIGA== X-Google-Smtp-Source: ADKCNb5XuhAuI4vKU1r7IVhz6nDZp/2xo8e5wyip7EAWuZ5UDsSNF8feWjT4tVG/Gz3meapGU8PtH0nFf0elJW3LVno= X-Received: by 10.36.82.148 with SMTP id d142mr645788itb.127.1504297797978; Fri, 01 Sep 2017 13:29:57 -0700 (PDT) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.107.155.195 with HTTP; Fri, 1 Sep 2017 13:29:17 -0700 (PDT) In-Reply-To: References: From: Sharon Goldberg Date: Fri, 1 Sep 2017 16:29:17 -0400 X-Google-Sender-Auth: aZlYk9rjWzE7wOEeYv6jwGs6-lo Message-ID: To: Daniel Franke Cc: Tal Mizrahi , "ntp@ietf.org" , "tictoc@ietf.org" , "Karen O'Donoghue" Content-Type: multipart/alternative; boundary="001a11448fa2e28fb60558269fc0" Archived-At: Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-ntp-mac 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: Fri, 01 Sep 2017 20:30:00 -0000 --001a11448fa2e28fb60558269fc0 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 1, 2017 at 4:23 PM, Daniel Franke wrote: > On 9/1/17, Sharon Goldberg wrote: > >> Less major comments: > >> - Missing security considerations section. > > > > Yes, will add. > > Oif, how'd I overlook that until now? Everything that needs discussion > is already discussed IMO, you just need to move it into a section with > the required title. > > Yes, that happened to me too :) Will do. Sharon --001a11448fa2e28fb60558269fc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 1, 2017 at 4:23 PM, Daniel Franke <dfoxfranke@gmail.com>= wrote:
On 9/1/17, Sharon Go= ldberg <goldbe@cs.= bu.edu> wrote:
>> Less major comments:
>> - Missing security considerations section.
>
> Yes, will add.

Oif, how'd I overlook that until now? Everything that needs disc= ussion
is already discussed IMO, you just need to move it into a section with
the required title.

Yes, that happened to me too :)=C2=A0 Wi= ll do.
=C2=A0
Sharon
--001a11448fa2e28fb60558269fc0-- From nobody Fri Sep 1 20:40:29 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 BAB08132FAE for ; Fri, 1 Sep 2017 20:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 LBCzmPQPqaWp for ; Fri, 1 Sep 2017 20:40:24 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA68132E87 for ; Fri, 1 Sep 2017 20:40:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 069F192243 for ; Sat, 2 Sep 2017 13:40:20 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNOphnS7QigK for ; Sat, 2 Sep 2017 13:40:11 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id C081E920F1 for ; Sat, 2 Sep 2017 13:40:10 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504323610; bh=mnC2Ay1Xl0x/Mp6nRS0TqdNiI0zDgetYoBOJdXDoWZE=; h=Subject:References:From:To:Date:In-Reply-To; b=fIqXdj1h9haYcTQhqGDnKInb/+gPpAUXQbBEsFA/A69IBZyLrSzRyfACSPM+Wh//R gEWq4MFOpu9yq32/GHMC0V8dPUM8LqlCQ+9xSR/eQn0721qKKanH8D9u2peUjBYgi7 EoL3PUIXUW58O6jNcfuF3+z4nQVigt7CoWOjrPoU= References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <59A52683020000A100027A58@gwsmtp1.uni-regensburg.de> From: Paul Gear To: ntp@ietf.org Message-ID: Date: Sat, 2 Sep 2017 13:40:10 +1000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------28F802DD28BE69823AF72826" Content-Language: en-AU Archived-At: Subject: [Ntp] On the Unique Identifier extension field [was WGLC for draft-ietf-ntp-using-nts-for-ntp (Objectives Subsection)] 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: Sat, 02 Sep 2017 03:40:27 -0000 This is a multi-part message in MIME format. --------------28F802DD28BE69823AF72826 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 29/08/17 23:16, kristof.teichel@ptb.de wrote: > "Ulrich Windl" schrieb am > 29.08.2017 10:32:03: > > Von: "Ulrich Windl" > > An: > > Datum: 29.08.2017 10:40 > > Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp > > (Objectives Subsection) > > > > Hi! > > > > I'm not deep in it, but the basic discussion seems to be that Dave > > Mills thinks some things are "good enough", while others think they > > are not. Maybe point out more clearly where any why things are not > > good enough. > > I must agree that I, too, see little practical difference between a > > sub-nanosecond timestamp and a random number (just to name one > > example), considering that the network delay is above microseconds. > > So the chances for a successful replay should be less than 1/1000th, > right? > > I guess this specific example is a matter of perspective: consciously > settling for ~1/(2^10) does not sound optimal to me when the > alternative is to go for ~1/(2^128), at the cost of a few additional > octets. > Also, I appreciate Daniel's point that it is simply good practice to > make the securtiy properties of a protection mechanism independent > from the content of the protected protocol. > > Additionally: do we have any argument that introducing a nonce (as per > good general practice) would actively be a significant detriment? Hi everyone, One of the things I've not been able to explain for myself in NTS draft 9 is why we need the Unique Identifier extension field. My logic is as follows: a) For clients which require unlinkability, NTS requires the use of Client Data Minimization. Such clients generate a 64-bit value "uniformly at random" for the Transmit Timestamp. This timestamp is authenticated by the NTS Authenticator and so any replay attack would need to replay the packet in its entirety (otherwise it would be ignored by the client as failing authentication). When a client following Client Data Minimization generates a Transmit Timestamp value to put in the packet, it must also save the real T1 locally in order to perform the correct time calculation when the reply arrives. So for a replay attack to succeed, it would need to both successfully match the Transmit Timestamp, and *correspond to an in-flight poll*. For a packet replayed after the original reply, this would not be the case. b) For NTS clients which do not require unlinkability, all of the same logic applies, except the Transmit Timestamp would have a much smaller range of possible values. However, all the same checks would need to be performed by the client, so again a replay attack would not be possible. c) For ordinary NTP clients which do not use NTS, all of the same logic still applies, except that in the absence of strong authentication, a MitM could forge a reply before the server's response was returned (although this is not really a replay attack). A reply after the server's response would again not correspond to an in-flight poll, so would be discarded. So it seems that in all scenarios, the Unique Identifier adds no benefit. What am I missing? If the answer is "nothing" and I've covered all the scenarios, then I'd like to see the Unique Identifier dropped, since it adds 32 unnecessary octets to the packet. Thanks in advance, Paul --------------28F802DD28BE69823AF72826 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 29/08/17 23:16, kristof.teichel@ptb.de wrote:
"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> schrieb am 29.08.2017 10:32:03:
> Von: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
> An: <kristof.teichel@ptb.de>
> Datum: 29.08.2017 10:40
> Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp
> (Objectives Subsection)
>
> Hi!
>
> I'm not deep in it, but the basic discussion seems to be that Dave
> Mills thinks some things are "good enough", while others think they
> are not. Maybe point out more clearly where any why things are not
> good enough.
> I must agree that I, too, see little practical difference between  a
> sub-nanosecond timestamp and a random number (just to name one
> example), considering that the network delay is above microseconds.
> So the chances for a successful replay should be less than 1/1000th, right?

I guess this specific example is a matter of perspective: consciously settling for ~1/(2^10) does not sound optimal to me when the alternative is to go for ~1/(2^128), at the cost of a few additional octets.
Also, I appreciate Daniel's point that it is simply good practice to make the securtiy properties of a protection mechanism independent from the content of the protected protocol.

Additionally: do we have any argument that introducing a nonce (as per good general practice) would actively be a significant detriment?

Hi everyone,

One of the things I've not been able to explain for myself in NTS draft 9 is why we need the Unique Identifier extension field.  My logic is as follows:

a) For clients which require unlinkability, NTS requires the use of Client Data Minimization.  Such clients generate a 64-bit value "uniformly at random" for the Transmit Timestamp.  This timestamp is authenticated by the NTS Authenticator and so any replay attack would need to replay the packet in its entirety (otherwise it would be ignored by the client as failing authentication).  When a client following Client Data Minimization generates a Transmit Timestamp value to put in the packet, it must also save the real T1 locally in order to perform the correct time calculation when the reply arrives.  So for a replay attack to succeed, it would need to both successfully match the Transmit Timestamp, and correspond to an in-flight poll.  For a packet replayed after the original reply, this would not be the case.

b) For NTS clients which do not require unlinkability, all of the same logic applies, except the Transmit Timestamp would have a much smaller range of possible values.  However, all the same checks would need to be performed by the client, so again a replay attack would not be possible.

c) For ordinary NTP clients which do not use NTS, all of the same logic still applies, except that in the absence of strong authentication, a MitM could forge a reply before the server's response was returned (although this is not really a replay attack).  A reply after the server's response would again not correspond to an in-flight poll, so would be discarded.

So it seems that in all scenarios, the Unique Identifier adds no benefit.  What am I missing?

If the answer is "nothing" and I've covered all the scenarios, then I'd like to see the Unique Identifier dropped, since it adds 32 unnecessary octets to the packet.

Thanks in advance,
Paul

--------------28F802DD28BE69823AF72826-- From ntp-bounces@ietf.org Fri Sep 1 20:40:29 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C66132F03; Fri, 1 Sep 2017 20:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504323629; bh=sc2TOFxa385mCwiFrgFdzxF28HBuR2TuhP2y279wBtc=; h=References:From:To:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=QWrdGFUOSJ7XjR7jMVW9z+Lp6hhqnX9V9gZVqjJS1B3vgbQWWG5RteT6WRjPhZT9C M4ScF6RbjlMpNojeG6fBgYbLi878oWZPZpEu9NE1ioB9RsmqQ4eGpHbJB0nrtf0v3t 9/hxF/3VY9Is82Sg5dpeo0A/0nX1BtoHs3haJPo0= 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 BAB08132FAE for ; Fri, 1 Sep 2017 20:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 LBCzmPQPqaWp for ; Fri, 1 Sep 2017 20:40:24 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA68132E87 for ; Fri, 1 Sep 2017 20:40:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 069F192243 for ; Sat, 2 Sep 2017 13:40:20 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNOphnS7QigK for ; Sat, 2 Sep 2017 13:40:11 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id C081E920F1 for ; Sat, 2 Sep 2017 13:40:10 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1504323610; bh=mnC2Ay1Xl0x/Mp6nRS0TqdNiI0zDgetYoBOJdXDoWZE=; h=Subject:References:From:To:Date:In-Reply-To; b=fIqXdj1h9haYcTQhqGDnKInb/+gPpAUXQbBEsFA/A69IBZyLrSzRyfACSPM+Wh//R gEWq4MFOpu9yq32/GHMC0V8dPUM8LqlCQ+9xSR/eQn0721qKKanH8D9u2peUjBYgi7 EoL3PUIXUW58O6jNcfuF3+z4nQVigt7CoWOjrPoU= References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org> <59A52683020000A100027A58@gwsmtp1.uni-regensburg.de> From: Paul Gear To: ntp@ietf.org Message-ID: Date: Sat, 2 Sep 2017 13:40:10 +1000 MIME-Version: 1.0 In-Reply-To: Content-Language: en-AU Archived-At: Subject: [Ntp] On the Unique Identifier extension field [was WGLC for draft-ietf-ntp-using-nts-for-ntp (Objectives Subsection)] 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: , Content-Type: multipart/mixed; boundary="===============2936859130026012510==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" This is a multi-part message in MIME format. --===============2936859130026012510== Content-Type: multipart/alternative; boundary="------------28F802DD28BE69823AF72826" Content-Language: en-AU This is a multi-part message in MIME format. --------------28F802DD28BE69823AF72826 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 29/08/17 23:16, kristof.teichel@ptb.de wrote: > "Ulrich Windl" schrieb am > 29.08.2017 10:32:03: > > Von: "Ulrich Windl" > > An: > > Datum: 29.08.2017 10:40 > > Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp > > (Objectives Subsection) > > > > Hi! > > > > I'm not deep in it, but the basic discussion seems to be that Dave > > Mills thinks some things are "good enough", while others think they > > are not. Maybe point out more clearly where any why things are not > > good enough. > > I must agree that I, too, see little practical difference between a > > sub-nanosecond timestamp and a random number (just to name one > > example), considering that the network delay is above microseconds. > > So the chances for a successful replay should be less than 1/1000th, > right? > > I guess this specific example is a matter of perspective: consciously > settling for ~1/(2^10) does not sound optimal to me when the > alternative is to go for ~1/(2^128), at the cost of a few additional > octets. > Also, I appreciate Daniel's point that it is simply good practice to > make the securtiy properties of a protection mechanism independent > from the content of the protected protocol. > > Additionally: do we have any argument that introducing a nonce (as per > good general practice) would actively be a significant detriment? Hi everyone, One of the things I've not been able to explain for myself in NTS draft 9 is why we need the Unique Identifier extension field. My logic is as follows: a) For clients which require unlinkability, NTS requires the use of Client Data Minimization. Such clients generate a 64-bit value "uniformly at random" for the Transmit Timestamp. This timestamp is authenticated by the NTS Authenticator and so any replay attack would need to replay the packet in its entirety (otherwise it would be ignored by the client as failing authentication). When a client following Client Data Minimization generates a Transmit Timestamp value to put in the packet, it must also save the real T1 locally in order to perform the correct time calculation when the reply arrives. So for a replay attack to succeed, it would need to both successfully match the Transmit Timestamp, and *correspond to an in-flight poll*. For a packet replayed after the original reply, this would not be the case. b) For NTS clients which do not require unlinkability, all of the same logic applies, except the Transmit Timestamp would have a much smaller range of possible values. However, all the same checks would need to be performed by the client, so again a replay attack would not be possible. c) For ordinary NTP clients which do not use NTS, all of the same logic still applies, except that in the absence of strong authentication, a MitM could forge a reply before the server's response was returned (although this is not really a replay attack). A reply after the server's response would again not correspond to an in-flight poll, so would be discarded. So it seems that in all scenarios, the Unique Identifier adds no benefit. What am I missing? If the answer is "nothing" and I've covered all the scenarios, then I'd like to see the Unique Identifier dropped, since it adds 32 unnecessary octets to the packet. Thanks in advance, Paul --------------28F802DD28BE69823AF72826 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 29/08/17 23:16, kristof.teichel@ptb.de wrote:
"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> schrieb am 29.08.2017 10:32:03:
> Von: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
> An: <kristof.teichel@ptb.de>
> Datum: 29.08.2017 10:40
> Betreff: Antw: [Ntp] [NTP] WGLC for draft-ietf-ntp-using-nts-for-ntp
> (Objectives Subsection)
>
> Hi!
>
> I'm not deep in it, but the basic discussion seems to be that Dave
> Mills thinks some things are "good enough", while others think they
> are not. Maybe point out more clearly where any why things are not
> good enough.
> I must agree that I, too, see little practical difference between  a
> sub-nanosecond timestamp and a random number (just to name one
> example), considering that the network delay is above microseconds.
> So the chances for a successful replay should be less than 1/1000th, right?

I guess this specific example is a matter of perspective: consciously settling for ~1/(2^10) does not sound optimal to me when the alternative is to go for ~1/(2^128), at the cost of a few additional octets.
Also, I appreciate Daniel's point that it is simply good practice to make the securtiy properties of a protection mechanism independent from the content of the protected protocol.

Additionally: do we have any argument that introducing a nonce (as per good general practice) would actively be a significant detriment?

Hi everyone,

One of the things I've not been able to explain for myself in NTS draft 9 is why we need the Unique Identifier extension field.  My logic is as follows:

a) For clients which require unlinkability, NTS requires the use of Client Data Minimization.  Such clients generate a 64-bit value "uniformly at random" for the Transmit Timestamp.  This timestamp is authenticated by the NTS Authenticator and so any replay attack would need to replay the packet in its entirety (otherwise it would be ignored by the client as failing authentication).  When a client following Client Data Minimization generates a Transmit Timestamp value to put in the packet, it must also save the real T1 locally in order to perform the correct time calculation when the reply arrives.  So for a replay attack to succeed, it would need to both successfully match the Transmit Timestamp, and correspond to an in-flight poll.  For a packet replayed after the original reply, this would not be the case.

b) For NTS clients which do not require unlinkability, all of the same logic applies, except the Transmit Timestamp would have a much smaller range of possible values.  However, all the same checks would need to be performed by the client, so again a replay attack would not be possible.

c) For ordinary NTP clients which do not use NTS, all of the same logic still applies, except that in the absence of strong authentication, a MitM could forge a reply before the server's response was returned (although this is not really a replay attack).  A reply after the server's response would again not correspond to an in-flight poll, so would be discarded.

So it seems that in all scenarios, the Unique Identifier adds no benefit.  What am I missing?

If the answer is "nothing" and I've covered all the scenarios, then I'd like to see the Unique Identifier dropped, since it adds 32 unnecessary octets to the packet.

Thanks in advance,
Paul

--------------28F802DD28BE69823AF72826-- --===============2936859130026012510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============2936859130026012510==-- From ntp-bounces@ietf.org Sun Sep 3 21:17:30 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8698D133033; Sun, 3 Sep 2017 21:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504498650; bh=dYGHhT3TvLyWvdbV6qz1TY0zEoDmdspBrJJ+yMPgMc4=; h=From:References:To:Date:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe; b=OGD6MIfnAcwSy323vJo3fOYC3rM2S6UeodklZKfw46EqL2LyKmEO6vDx44s2jc8U8 EJToUaI6F6zpkn/BuJZvsnfOF/bNkv60DY6VGI+twYoAko9ruFjiMSx6rsRbx0ca1p 98WNqgexAie5mvC9VlRped2/l835M0+O1glwVvvg= 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 43F1413302A for ; Sun, 3 Sep 2017 21:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 KKXbjiCLefIY for ; Sun, 3 Sep 2017 21:17:27 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2063D1352E2 for ; Sun, 3 Sep 2017 20:09:37 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id 8051E1759CF for ; Sun, 3 Sep 2017 20:09:37 -0700 (PDT) Received: (qmail 22593 invoked from network); 4 Sep 2017 03:09:37 -0000 Received: from c-67-188-112-34.hsd1.ca.comcast.net (HELO ?10.0.200.101?) (ask@mail.dev@67.188.112.34) by smtp.develooper.com with ESMTPA; 4 Sep 2017 03:09:37 -0000 From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Message-Id: References: <6BC098EF-6EE6-48BE-A684-30E4325E1188@develooper.com> To: ntp@ietf.org Date: Sun, 3 Sep 2017 20:09:24 -0700 X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: [Ntp] 9.3. Usage of NTP pools 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntp-bounces@ietf.org Sender: "ntp" SSBzZW50IHRoaXMgZWFybGllciBpbiB0aGUgd2VlaywgYnV0IGl0IGRvZXNu4oCZdCBzZWVtIGxp a2UgaXQgbWFkZSB0byBpdCB0byB0aGUgbGlzdC4KClsgU3BlYWtpbmcgYXMgdGhlIE5UUCBQb29s IG1haW50YWluZXIgYW5kIG5vdCBmb3IgYW55b25lIG9yIGFueXRoaW5nIGVsc2UgXQoKPiA5LjMu ICBVc2FnZSBvZiBOVFAgcG9vbHMKPiAKPiAgQWRkaXRpb25hbCBzdGFuZGFyZGl6YXRpb24gd29y ayBhbmQgaW5mcmFzdHJ1Y3R1cmUgZGV2ZWxvcG1lbnQgaXMKPiAgbmVjZXNzYXJ5IGJlZm9yZSBO VFMgY2FuIGJlIHVzZWQgd2l0aCBwdWJsaWMgTlRQIHNlcnZlciBwb29scy4KPiAgRmlyc3QsIGEg c2NoZW1lIG5lZWRzIHRvIGJlIHNwZWNpZmllZCBmb3IgZGV0ZXJtaW5pbmcgd2hhdAo+ICBjb25z dGl0dXRlcyBhbiBhY2NlcHRhYmxlIGNlcnRpZmljYXRlIGZvciBhIHBvb2wgc2VydmVyLCBzdWNo IGFzCj4gIGVzdGFibGlzaGluZyBhIHZhbHVlIHJlcXVpcmVkIHRvIGJlIGNvbnRhaW5lZCBpbiBp dHMgRXh0ZW5kZWQgS2V5Cj4gIFVzYWdlIGF0dHJpYnV0ZSwgYW5kIGhvdyB0byBkZXRlcm1pbmUs IGdpdmVuIHRoZSBETlMgbmFtZSBvZiBhIHBvb2wsCj4gIHdoYXQgU3ViamVjdCBBbHRlcm5hdGl2 ZSBOYW1lIHRvIGV4cGVjdCBpbiB0aGUgY2VydGlmaWNhdGVzIG9mIGl0cwo+ICBtZW1iZXJzLgoK SSBkb27igJl0IHRoaW5rIHRoZXJl4oCZcyBhIHByYWN0aWNhbCB3YXkgdG8gbWFuYWdlIHRob3Vz YW5kcyBvZiBpbmRlcGVuZGVudGx5IHJ1biBzZXJ2ZXJzIGFsbCB1c2luZyB0aGUgc2FtZSAoc2V0 IG9mKSDigJxwb29sLWRvbWFpbihzKeKAnSBhbmQgZ2FpbiBhbnkgbmV3IHNlY3VyaXR5IGJlbmVm aXRzLgoKSWYgTlRQIGNsaWVudHMgc3VwcG9ydGVkIFNSViByZWNvcmRzIHRoZXJlIGNvdWxkIGJl IGEgc2NoZW1lIGZvciBhIHBvb2wgdG8g4oCcZGVsZWdhdGXigJ0gc2VydmluZyB0aW1lLCBpbmNs dWRpbmcgdGhlIG5hbWUsIHNvCgogcG9vbC5leGFtcGxlLmNvbSBTUlYgMTAgMCAxMjMgc29tZS5z ZXJ2ZXIuZXhhbXBsZS5vcmcuCiBwb29sLmV4YW1wbGUuY29tIFNSViAxMCAwIDEyMyBhbm90aGVy LmV4YW1wbGUubmV0LgoKd291bGQgaGF2ZSB0aGUgY2xpZW50IHRhbGsgdG8gc29tZS5zZXJ2ZXIu ZXhhbXBsZS5vcmcgYW5kIGFub3RoZXIuZXhhbXBsZS5jb20gZXhwZWN0aW5nIHRob3NlIG5hbWVz IGluIHRoZSBjZXJ0aWZpY2F0ZXMgcmF0aGVyIHRoYW4gcG9vbC5leGFtcGxlLmNvbS4gKFRoaXMg YXNzdW1lcyBETlNTRUMgZm9yIHBvb2wuZXhhbXBsZS5jb20gdG8gbWFrZSBzZW5zZSkuCgpJdOKA mWQgYmUgYmV0dGVyIHRoYW4gYSBsYXJnZSBudW1iZXIgb2Ygc2VydmVycyBhbGwgaGF2aW5nIHRo ZSBzYW1lIGNlcnRpZmljYXRlIGluIHRoYXQgYW4gYXR0YWNrZXIgY2Fu4oCZdCBqdXN0IE1JVE0g d2l0aCBhIHZhbGlkIGNlcnRpZmljYXRlLCBidXQgYWxzbyBoYXZlIHRvIGdldCB0aGUgY2xpZW50 IHRvIHdhbnQgdG8gdGFsayB0byB0aGF0IHBhcnRpY3VsYXIgc2VydmVyICh2ZXJzdXMgYW55IHNl cnZlciBpbiBwb29sIHN5c3RlbSkuCgooSSBkb27igJl0IHRoaW5rIEkgZXhwbGFpbmVkIHRoYXQg aWRlYSB2ZXJ5IHdlbGwpLgoKPiAgQSBtb3JlIGltcG9ydGFudCBtYXR0ZXIsIGhvd2V2ZXIsIGlz IHRoYXQgcG9vbCBvcGVyYXRvcnMKPiAgbmVlZCBwcm9jZWR1cmVzIGZvciBlc3RhYmxpc2hpbmcg YW5kIG1haW50YWluaW5nIHRydXN0IGluIHRoZWlyCj4gIG1lbWJlcnMuICBQb29scyBpbiBleGlz dGVuY2UgYXMgb2YgMjAxNyBhcmUgdm9sdW50ZWVyLXJ1biwgd2l0aAo+ICBtaW5pbWFsIHJlcXVp cmVtZW50cyBmb3IgYWRtaXNzaW9uIGFuZCBubyBvcmdhbml6ZWQgZWZmb3J0IHRvIG1vbml0b3IK PiAgcG9vbCBzZXJ2ZXJzIGZvciBtaXNiZWhhdmlvci4KCkFzc3VtaW5nIHRoaXMgaXMgcmVmZXJy aW5nIHRvIHRoZSBudHBwb29sLm9yZyAvIHd3dy5wb29sLm50cC5vcmcgc3lzdGVtIHRoaXMgaXMg ZWl0aGVyIHZlcnkgdmFndWUgb3IgaW5jb3JyZWN0LgoKSeKAmW0gbm90IHN1cmUgd2hhdCB3b3Jr IHdvdWxkIGJlIGNvbnNpZGVyZWQgYW4g4oCcb3JnYW5pemVkIGVmZm9ydCB0byBtb25pdG9y4oCd LCBidXQgdGhlIE5UUCBQb29sIHN5c3RlbSBkb2VzIG1vbml0b3IgdGhlIHRpbWUgYWNjdXJhY3ks IGxlYXAgc2Vjb25kIGZsYWdzIGFuZCBvdGhlciBhdHRyaWJ1dGVzIG9mIGFsbCB0aGUgc2VydmVy cy4gV2UgYWxzbyByZWd1bGFybHkgd29yayB3aXRoIHJlc2VhcmNoZXJzIGFuZCBvdGhlcnMgdG8g ZG8gb3RoZXIg4oCcZGlhZ25vc3RpY3PigJ0gYWNyb3NzIHRoZSBzeXN0ZW0uCgooT2YgY291cnNl IG5vdGhpbmcgaXMgdG8gc3RvcCBhIHNlcnZlciBvcGVyYXRvciBmcm9tIHRhcmdldGluZyBzcGVj aWZpYyBzb3VyY2UgSVBzIGZvciDigJxiYWQgdGltZeKAnSwgYnV0IGZyb20gdGhlIGRhdGEgSSBo YXZlIHRoZSBhdmVyYWdlIHBvb2wgc2VydmVyIGJlaGF2ZXMgYXMgd2VsbCBvciBiZXR0ZXIgYXMg YW55IG90aGVyIGF2ZXJhZ2UgcHVibGljIE5UUCBzZXJ2ZXIsIGluY2x1ZGluZyB2YXJpb3VzIG5h dGlvbmFsIOKAnHRpbWUgcmVmZXJlbmNlc+KAnVsxXSkuCgpJ4oCZZCBzdWdnZXN0IHRoZSBsYXN0 IHNlbnRlbmNlIGFib3ZlIGFuZCB0aGUgbmV4dCBiZWxvdyBlaXRoZXIgYmUgdGFrZW4gb3V0IG9y IGJlIHJld3JpdHRlbiB3aXRoIGEgc2VjdGlvbiBvZiB3aGF0IHRoZSByZXF1aXJlbWVudHMgZm9y IG1vbml0b3JpbmcgbWlzYmVoYXZpb3Igc2hvdWxkIGJlLCBpbiB0aGUgZWRpdG9ycyBvcGluaW9u ICh0aG91Z2ggdGhhdCBzZWVtcyBvdXQgb2Ygc2NvcGUpLgoKPiAgV2l0aG91dCBhbnkgc29ydCBv ZiBwb2xpY2luZyBpbiBwbGFjZSwKPiAgdGhlcmUgaXMgbm90aGluZyB0byBwcmV2ZW50IGFuIGFk dmVyc2FyeSBmcm9tIGdvaW5nIHRocm91Z2ggbm9ybWFsCj4gIGNoYW5uZWxzIHRvIG9idGFpbiBh IHZhbGlkIGNlcnRpZmljYXRlIGZvciBwYXJ0aWNpcGF0aW9uIGluIGEgcG9vbAo+ICBhbmQgdGhl biBwcm9jZWVkaW5nIHRvIHNlcnZlIG1hbGljaW91c2x5IGluYWNjdXJhdGUgdGltZS4KCkZvciBh biBhdHRhY2tlciB3aXRoIGEgc3BlY2lmaWMgdGFyZ2V0IGluIG1pbmQgdGhlIHByb3RlY3Rpb24g YWdhaW5zdCB0aGlzIGlzIHRoZSBjbGllbnQgYmVpbmcgY29uc2VydmF0aXZlIGFib3V0IHdoYXQg aXQgYmVsaWV2ZXMgYW5kIHVzaW5nIG11bHRpcGxlIHNlcnZlcnMuIE15IHN1Z2dlc3RlZCBzY2hl bWUgYWJvdmUgd291bGQgbWFrZSBpdCBoYXJkZXIgdG8gdGFrZSBvdmVyIGFsbCB0aGUgTlRQIHRy YWZmaWMgZm9yIGEgdGFyZ2V0IGFuZCBlYXNpZXIgZm9yIHRoZSBjbGllbnQgdG8gZXhjbHVkZSB0 aGUgbWFsaWNpb3VzIHNlcnZlcnMuCgoKQXNrCgpbMV0gV2XigJl2ZSBub3RpY2VkIG5hdGlvbmFs IHRpbWUgcmVmZXJlbmNlcyBiZWluZyBvdmVybG9hZGVkLCBoYXZlIGluY29ycmVjdCBsZWFwIHNl Y29uZCBmbGFncywgZ2VuZXJhbGx5IGJlIGluLWFjY3VyYXRlLCBldGMgZXRjLiBHZW5lcmFsaXpl ZCBzbGlnaHRseSwgZGVwbG95ZWQgdGltZSBrZWVwaW5nIGFuZCBOVFAgaW1wbGVtZW50YXRpb25z IGFuZCB0aGUgcXVhbGl0eSBvZiB0aGUgb3BlcmF0aW9ucyBvZiB0aGVtIGFyZSBub3QgdmVyeSBn b29kLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm50 cCBtYWlsaW5nIGxpc3QKbnRwQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbnRwCg== From nobody Sun Sep 3 21:17:31 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 43F1413302A for ; Sun, 3 Sep 2017 21:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 KKXbjiCLefIY for ; Sun, 3 Sep 2017 21:17:27 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2063D1352E2 for ; Sun, 3 Sep 2017 20:09:37 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id 8051E1759CF for ; Sun, 3 Sep 2017 20:09:37 -0700 (PDT) Received: (qmail 22593 invoked from network); 4 Sep 2017 03:09:37 -0000 Received: from c-67-188-112-34.hsd1.ca.comcast.net (HELO ?10.0.200.101?) (ask@mail.dev@67.188.112.34) by smtp.develooper.com with ESMTPA; 4 Sep 2017 03:09:37 -0000 From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Message-Id: References: <6BC098EF-6EE6-48BE-A684-30E4325E1188@develooper.com> To: ntp@ietf.org Date: Sun, 3 Sep 2017 20:09:24 -0700 X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: [Ntp] 9.3. Usage of NTP pools 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, 04 Sep 2017 04:17:29 -0000 I sent this earlier in the week, but it doesn=E2=80=99t seem like it = made to it to the list. [ Speaking as the NTP Pool maintainer and not for anyone or anything = else ] > 9.3. Usage of NTP pools >=20 > Additional standardization work and infrastructure development is > necessary before NTS can be used with public NTP server pools. > First, a scheme needs to be specified for determining what > constitutes an acceptable certificate for a pool server, such as > establishing a value required to be contained in its Extended Key > Usage attribute, and how to determine, given the DNS name of a pool, > what Subject Alternative Name to expect in the certificates of its > members. I don=E2=80=99t think there=E2=80=99s a practical way to manage = thousands of independently run servers all using the same (set of) = =E2=80=9Cpool-domain(s)=E2=80=9D and gain any new security benefits. If NTP clients supported SRV records there could be a scheme for a pool = to =E2=80=9Cdelegate=E2=80=9D serving time, including the name, so pool.example.com SRV 10 0 123 some.server.example.org. pool.example.com SRV 10 0 123 another.example.net. would have the client talk to some.server.example.org and = another.example.com expecting those names in the certificates rather = than pool.example.com. (This assumes DNSSEC for pool.example.com to make = sense). It=E2=80=99d be better than a large number of servers all having the = same certificate in that an attacker can=E2=80=99t just MITM with a = valid certificate, but also have to get the client to want to talk to = that particular server (versus any server in pool system). (I don=E2=80=99t think I explained that idea very well). > A more important matter, however, is that pool operators > need procedures for establishing and maintaining trust in their > members. Pools in existence as of 2017 are volunteer-run, with > minimal requirements for admission and no organized effort to monitor > pool servers for misbehavior. Assuming this is referring to the ntppool.org / www.pool.ntp.org system = this is either very vague or incorrect. I=E2=80=99m not sure what work would be considered an =E2=80=9Corganized = effort to monitor=E2=80=9D, but the NTP Pool system does monitor the = time accuracy, leap second flags and other attributes of all the = servers. We also regularly work with researchers and others to do other = =E2=80=9Cdiagnostics=E2=80=9D across the system. (Of course nothing is to stop a server operator from targeting specific = source IPs for =E2=80=9Cbad time=E2=80=9D, but from the data I have the = average pool server behaves as well or better as any other average = public NTP server, including various national =E2=80=9Ctime = references=E2=80=9D[1]). I=E2=80=99d suggest the last sentence above and the next below either be = taken out or be rewritten with a section of what the requirements for = monitoring misbehavior should be, in the editors opinion (though that = seems out of scope). > Without any sort of policing in place, > there is nothing to prevent an adversary from going through normal > channels to obtain a valid certificate for participation in a pool > and then proceeding to serve maliciously inaccurate time. For an attacker with a specific target in mind the protection against = this is the client being conservative about what it believes and using = multiple servers. My suggested scheme above would make it harder to take = over all the NTP traffic for a target and easier for the client to = exclude the malicious servers. Ask [1] We=E2=80=99ve noticed national time references being overloaded, = have incorrect leap second flags, generally be in-accurate, etc etc. = Generalized slightly, deployed time keeping and NTP implementations and = the quality of the operations of them are not very good. From nobody Tue Sep 5 00:36: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 21AB01326FE for ; Tue, 5 Sep 2017 00:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 pvMlGaziARfh for ; Tue, 5 Sep 2017 00:36:42 -0700 (PDT) Received: from relay77.bu.edu (relay77.bu.edu [128.197.228.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800AF1326EA for ; Tue, 5 Sep 2017 00:36:41 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by relay77.bu.edu (8.14.3/8.14.3) with ESMTP id v857ZlRi029300 for ; Tue, 5 Sep 2017 03:35:47 -0400 Received: by mail-lf0-f70.google.com with SMTP id 80so1191424lfy.5 for ; Tue, 05 Sep 2017 00:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QfEeE94dkMnc+9S6tw0ePanU7Ok6NN0awwcXF4xwqA4=; b=GpATD/ZNlhwTdG2YOqNKPtV6NidvGhWU6dnUGEeGa/zdmIPAhWwmyhxj7kGML7En5n N/4r8QXXBVNwZQm80YmbtSLL+2A7i4zDt3j3NKMac4u/NN7XKwKXOLJWuDUXc032c0iQ fgxxlFd5qjIPN2ni6pP6+gktzyYzs9w7iModj+ZT3yYg7mngrkdR9jZEhqVtPvkUJiUg ojzB67d2g4J/5O7owSDjbtPdPVCPzQc5vr+CvCG+POWTCgcuLUlpPzJlGFAYWu3mCEDT CbrBoeMnihbobMl21HPk/cOqqztUwBigPwOe/7dn3KT3v9V8fz/LKdsT686FpeE4csW4 lXIQ== X-Gm-Message-State: AHPjjUhsM3kGnTvLoB0EXGv8h+cVTduxP9Te155j8/K+NF+dokGCLtge bPUsseKq6gGyhfkMH1alAMw3RaYM/iCwXOTy94HFEXJpW062P453nVEeAAgqboANZeRzcuDGfmA zKEWt+p9An/8= X-Received: by 10.25.208.137 with SMTP id h131mr961146lfg.101.1504596946874; Tue, 05 Sep 2017 00:35:46 -0700 (PDT) X-Google-Smtp-Source: ADKCNb44ta72p/U9YBP2Dq7y3cfbVcXqZqfPDzFEyPUxcKSDx3FYN/tHIjivA+BIooHkLuo8rdgYCQa4r6AIKQJuLmc= X-Received: by 10.25.208.137 with SMTP id h131mr961141lfg.101.1504596946567; Tue, 05 Sep 2017 00:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.67.189 with HTTP; Tue, 5 Sep 2017 00:35:26 -0700 (PDT) From: Aanchal Malhotra Date: Tue, 5 Sep 2017 09:35:26 +0200 Message-ID: To: ntp@ietf.org Content-Type: multipart/alternative; boundary="001a11412da887dc2405586c4623" Archived-At: Subject: [Ntp] Comments on NTS - Aanchal Malhotra 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, 05 Sep 2017 07:36:50 -0000 --001a11412da887dc2405586c4623 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Sorry for the late review. I am unwell and so away from emails. I think the document is great but few sections remain inadequately explained. I would like to do another pass and may be even have another WG call before going forward. Please read my following comments. *Section 1.1* Aren't the objectives of NTS different for different modes? e.g. 1) The following objective is not true for client/server mode, since the server does not have this privilege. " *Replay prevention: Implementations may detect when a received time synchronization packet is a replay of a previous packet."* 2) The usage of the terms client and server in the following objective is confusing. Does it refer to NTP client/server mode? Does it refer to any implementation? "*Request-response consistency: Client implementations may verify that a time synchronization packet received from a server was sent in response to a particular request from the client*." Similar problems with the 'Unlinkability' and 'Scalability' objectives. I think it would be worth stating separately the Objectives of NTS for different modes. And make use of the terms client and server to only refer to NTP's client server mode participants. In fact the first para of section 1.2 could be used to justify the different objectives of NTS for different modes and could be placed before/in section 1.1 *Section 1.2* "*it is harmless for servers to process replayed packets*" I do not agree with the statement above. In addition to Sharon=E2=80=99s ob= jection, in NTS, the server can be DoSd in terms of resources by replaying query packets because it has to do more work than normal NTP. Minor comment: Section 1.2 The last and second to last paras are 2 parts of the same thing. Putting them in 2 points makes it more readable. *Section 4.* I feel like this section requires more discussion on the length of sessions. Like what is the typical frequency of symmetric peer exchanges and correspondingly what is the typical length of a DTLS session? When will it time out? How often do the peers have to re-establish DTLS session? How do they know? Similar questions for control mode and client/server mode. Overall, this section needs more explanation. =E2=80=9C*The two endpoints carry out a DTLS handshake in conformance with = Section 3, with the client offering (via an ALPN [RFC7301] extension), and the server accepting, an application-layer protocol of "ntp/4"*. Again term client/server is overloaded. This is supposed to be DTLS client and DTLS server and not NTP mode3/4 client server. Also, add =E2=80=9CFirst=E2=80=9D in the beginning of sentence. *Section 5* The interpretation of critical bit C seems confusing. How is the figure 2 parsed by the client? The interpretation of C is Record Type dependent. Why in section 5.1.5 "C is MAY and not MUST? How is this bit interpreted when it is 0 or when it is 1? Also, in section 5.1.6 "C SHOULD NOT be set". Again, what does the client do if he finds it set? IMO, this section is very high level description and not very fluent from implementation point of view. As written now, it is very difficult to follow. May be we can have a table with all possible combinations of C and record types and the corresponding action taken by client or the server. *Section 6* =E2=80=9C*Upon receiving an NTS-protected response, the client MUST verify = that the Unique Identifier matches =E2=80=A6=E2=80=A6=E2=80=A6 which sent the NA= K and initiate a fresh NTS-KE handshake.*=E2=80=9D This section is understated and requires much more detailed explanation. The order in which client performs the checks and the corresponding changes it makes to the internal state variables is important to mention as this has lead to several implementation flaws in the past. For instance, 1) If the UID match passes, the client checks for crypto. Then there are two cases: a) If crypto is fine, client processes the packet and stops listening for any response corresponding to this UID. b) If crypto fails, it does not process the packet and stops listening for the response corresponding to this UID. 2) If the UID match fails, the client should not check for crypto. AND must still keep listening for the packets corresponding to the stored UID. (Otherwise an easy off-path attack.) This is just an example. There are several other cases and it is IMPORTANT to mention the state variable changes in EACH case. We should discuss/talk about it and sort this out. Thanks, Aanchal Malhotra. --001a11412da887dc2405586c4623 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Sorry for the late review. I am unwe= ll and so away from emails.=C2=A0 I think the document is great but few sections remain= =20 inadequately explained. I would like to do another pass and may be even=20 have another WG call before going forward. Please read my following=20 comments.

Section 1.1

Aren't the objectives of NT= S different for different modes? e.g.

1) The following objective is = not true for client/server mode, since the server does not have this privil= ege.

"Replay prevention: Implementations may detect when a r= eceived time synchronization packet is a replay of a previous packet."=

2) The usage of the terms client and server in the following objective is=20 confusing. Does it refer to NTP client/server mode? Does it refer to any implementation?

"Request-response consistency: Client=20 implementations may verify that a time synchronization packet received=20 from a server was sent in response to a particular request from the=20 client."

Similar problems with the 'Unlinkability' = and=20 'Scalability' objectives. I think it would be worth stating separat= ely=20 the Objectives of NTS for different modes. And make use of the terms=20 client and server to only refer to NTP's client server mode=20 participants.
In fact the first para of section 1.2 could be used to=20 justify the different objectives of NTS for different modes and could be placed before/in section 1.1

Section 1.2

"it = is harmless for servers to process replayed packets"

I do not agree with the statement above. In addition to Sharon=E2=80=99s=20 objection, in NTS, the server can be DoSd in terms of resources by=20 replaying query packets because it has to do more work than normal NTP.
=
Minor comment: Section 1.2 The last and second to last paras are 2 parts of=20 the same thing. Putting them in 2 points makes it more readable.

= Section 4.

I feel like this section requires more discussion on the length of=20 sessions. Like what is the typical frequency of symmetric peer exchanges and correspondingly what is the typical length of a DTLS session? When=20 will it time out? How often do the peers have to re-establish DTLS=20 session? How do they know? Similar questions for control mode and=20 client/server mode.

Overall, this section needs more explanation.
=E2=80=9CThe two endpoints carry out a DTLS handshake in conformance with Section 3, with the client offering (via an ALPN [RFC7301] extension), and the=20 server accepting, an application-layer protocol of "ntp/4".
Again term client/server is overloaded. This is supposed to be DTLS c= lient and DTLS server and not NTP mode3/4 client server.

Also, add = =E2=80=9CFirst=E2=80=9D in the beginning of sentence.

Section 5
The interpretation of critical bit C seems confusing. How is the figure 2=20 parsed by the client? The interpretation of C is Record Type dependent.
=
Why in section 5.1.5 "C is MAY and not MUST? How is this bit inter= preted when it is 0 or when it is 1?

Also, in section 5.1.6=C2=A0 &q= uot;C SHOULD NOT be set". Again, what does the client do if he finds i= t set?

IMO, this section is very high level description and not very fluent from=20 implementation point of view. As written now, it is very difficult to=20 follow. May be we can have a table with all possible combinations of C=20 and record types and the corresponding action taken by client or the=20 server.

Section 6

=E2=80=9CUpon receiving an=20 NTS-protected response, the client MUST verify that=C2=A0 the Unique=20 Identifier matches =E2=80=A6=E2=80=A6=E2=80=A6 which sent the NAK and initi= ate a fresh NTS-KE=20 handshake.=E2=80=9D

This section is understated and requires muc= h=20 more detailed explanation. The order in which client performs the checks and the corresponding changes it makes to the internal state variables=20 is important to mention as this has lead to several implementation flaws in the past. For instance,

1) If the UID match passes, the client c= hecks for crypto. Then there are two cases:

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a) If crypto is fine, client processes the p= acket and stops listening for any response corresponding to this UID.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b) If crypto fails, it doe= s not process the packet and=20 stops listening for the response corresponding to this UID.

2) If the UID match fails, the client should not check for crypto. AND must=20 still keep listening for the packets corresponding to the stored UID.=20 (Otherwise an easy off-path attack.)

This is just an example.=20 There are several other cases and it is IMPORTANT to mention the state=20 variable changes in EACH case. We should discuss/talk about it and sort=20 this out.

Thanks,
Aanchal Malhotra.
--001a11412da887dc2405586c4623-- From ntp-bounces@ietf.org Tue Sep 5 00:36:52 2017 Return-Path: X-Original-To: ntp-archives-ahfae6za@lists.ietf.org Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E99E81326FE; Tue, 5 Sep 2017 00:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1504597012; bh=jyATJ1K7grMUByefFVNAz8X3jsGAb1rQolelYgOsBkU=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=p+kER3L/laS8CkyvISplITcKDJKoVIo7hNI/6p9P69IYk6ZBwFUV/AYiqDHcWy39N UhtL4RpFJEWj8DMHJkRKtKrv3NFhNK0sQ0JpPMZ4PjuZqxZ+r0pC9X7+c39audp6FD +spBDVlfMJCDXwMJHWPFf4FVLlz06eHTlniD0qzI= 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 21AB01326FE for ; Tue, 5 Sep 2017 00:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 pvMlGaziARfh for ; Tue, 5 Sep 2017 00:36:42 -0700 (PDT) Received: from relay77.bu.edu (relay77.bu.edu [128.197.228.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800AF1326EA for ; Tue, 5 Sep 2017 00:36:41 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by relay77.bu.edu (8.14.3/8.14.3) with ESMTP id v857ZlRi029300 for ; Tue, 5 Sep 2017 03:35:47 -0400 Received: by mail-lf0-f70.google.com with SMTP id 80so1191424lfy.5 for ; Tue, 05 Sep 2017 00:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QfEeE94dkMnc+9S6tw0ePanU7Ok6NN0awwcXF4xwqA4=; b=GpATD/ZNlhwTdG2YOqNKPtV6NidvGhWU6dnUGEeGa/zdmIPAhWwmyhxj7kGML7En5n N/4r8QXXBVNwZQm80YmbtSLL+2A7i4zDt3j3NKMac4u/NN7XKwKXOLJWuDUXc032c0iQ fgxxlFd5qjIPN2ni6pP6+gktzyYzs9w7iModj+ZT3yYg7mngrkdR9jZEhqVtPvkUJiUg ojzB67d2g4J/5O7owSDjbtPdPVCPzQc5vr+CvCG+POWTCgcuLUlpPzJlGFAYWu3mCEDT CbrBoeMnihbobMl21HPk/cOqqztUwBigPwOe/7dn3KT3v9V8fz/LKdsT686FpeE4csW4 lXIQ== X-Gm-Message-State: AHPjjUhsM3kGnTvLoB0EXGv8h+cVTduxP9Te155j8/K+NF+dokGCLtge bPUsseKq6gGyhfkMH1alAMw3RaYM/iCwXOTy94HFEXJpW062P453nVEeAAgqboANZeRzcuDGfmA zKEWt+p9An/8= X-Received: by 10.25.208.137 with SMTP id h131mr961146lfg.101.1504596946874; Tue, 05 Sep 2017 00:35:46 -0700 (PDT) X-Google-Smtp-Source: ADKCNb44ta72p/U9YBP2Dq7y3cfbVcXqZqfPDzFEyPUxcKSDx3FYN/tHIjivA+BIooHkLuo8rdgYCQa4r6AIKQJuLmc= X-Received: by 10.25.208.137 with SMTP id h131mr961141lfg.101.1504596946567; Tue, 05 Sep 2017 00:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.67.189 with HTTP; Tue, 5 Sep 2017 00:35:26 -0700 (PDT) From: Aanchal Malhotra Date: Tue, 5 Sep 2017 09:35:26 +0200 Message-ID: To: ntp@ietf.org Archived-At: Subject: [Ntp] Comments on NTS - Aanchal Malhotra 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: , Content-Type: multipart/mixed; boundary="===============7232734198416360266==" Errors-To: ntp-bounces@ietf.org Sender: "ntp" --===============7232734198416360266== Content-Type: multipart/alternative; boundary="001a11412da887dc2405586c4623" --001a11412da887dc2405586c4623 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Sorry for the late review. I am unwell and so away from emails. I think the document is great but few sections remain inadequately explained. I would like to do another pass and may be even have another WG call before going forward. Please read my following comments. *Section 1.1* Aren't the objectives of NTS different for different modes? e.g. 1) The following objective is not true for client/server mode, since the server does not have this privilege. " *Replay prevention: Implementations may detect when a received time synchronization packet is a replay of a previous packet."* 2) The usage of the terms client and server in the following objective is confusing. Does it refer to NTP client/server mode? Does it refer to any implementation? "*Request-response consistency: Client implementations may verify that a time synchronization packet received from a server was sent in response to a particular request from the client*." Similar problems with the 'Unlinkability' and 'Scalability' objectives. I think it would be worth stating separately the Objectives of NTS for different modes. And make use of the terms client and server to only refer to NTP's client server mode participants. In fact the first para of section 1.2 could be used to justify the different objectives of NTS for different modes and could be placed before/in section 1.1 *Section 1.2* "*it is harmless for servers to process replayed packets*" I do not agree with the statement above. In addition to Sharon=E2=80=99s ob= jection, in NTS, the server can be DoSd in terms of resources by replaying query packets because it has to do more work than normal NTP. Minor comment: Section 1.2 The last and second to last paras are 2 parts of the same thing. Putting them in 2 points makes it more readable. *Section 4.* I feel like this section requires more discussion on the length of sessions. Like what is the typical frequency of symmetric peer exchanges and correspondingly what is the typical length of a DTLS session? When will it time out? How often do the peers have to re-establish DTLS session? How do they know? Similar questions for control mode and client/server mode. Overall, this section needs more explanation. =E2=80=9C*The two endpoints carry out a DTLS handshake in conformance with = Section 3, with the client offering (via an ALPN [RFC7301] extension), and the server accepting, an application-layer protocol of "ntp/4"*. Again term client/server is overloaded. This is supposed to be DTLS client and DTLS server and not NTP mode3/4 client server. Also, add =E2=80=9CFirst=E2=80=9D in the beginning of sentence. *Section 5* The interpretation of critical bit C seems confusing. How is the figure 2 parsed by the client? The interpretation of C is Record Type dependent. Why in section 5.1.5 "C is MAY and not MUST? How is this bit interpreted when it is 0 or when it is 1? Also, in section 5.1.6 "C SHOULD NOT be set". Again, what does the client do if he finds it set? IMO, this section is very high level description and not very fluent from implementation point of view. As written now, it is very difficult to follow. May be we can have a table with all possible combinations of C and record types and the corresponding action taken by client or the server. *Section 6* =E2=80=9C*Upon receiving an NTS-protected response, the client MUST verify = that the Unique Identifier matches =E2=80=A6=E2=80=A6=E2=80=A6 which sent the NA= K and initiate a fresh NTS-KE handshake.*=E2=80=9D This section is understated and requires much more detailed explanation. The order in which client performs the checks and the corresponding changes it makes to the internal state variables is important to mention as this has lead to several implementation flaws in the past. For instance, 1) If the UID match passes, the client checks for crypto. Then there are two cases: a) If crypto is fine, client processes the packet and stops listening for any response corresponding to this UID. b) If crypto fails, it does not process the packet and stops listening for the response corresponding to this UID. 2) If the UID match fails, the client should not check for crypto. AND must still keep listening for the packets corresponding to the stored UID. (Otherwise an easy off-path attack.) This is just an example. There are several other cases and it is IMPORTANT to mention the state variable changes in EACH case. We should discuss/talk about it and sort this out. Thanks, Aanchal Malhotra. --001a11412da887dc2405586c4623 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Sorry for the late review. I am unwe= ll and so away from emails.=C2=A0 I think the document is great but few sections remain= =20 inadequately explained. I would like to do another pass and may be even=20 have another WG call before going forward. Please read my following=20 comments.

Section 1.1

Aren't the objectives of NT= S different for different modes? e.g.

1) The following objective is = not true for client/server mode, since the server does not have this privil= ege.

"Replay prevention: Implementations may detect when a r= eceived time synchronization packet is a replay of a previous packet."=

2) The usage of the terms client and server in the following objective is=20 confusing. Does it refer to NTP client/server mode? Does it refer to any implementation?

"Request-response consistency: Client=20 implementations may verify that a time synchronization packet received=20 from a server was sent in response to a particular request from the=20 client."

Similar problems with the 'Unlinkability' = and=20 'Scalability' objectives. I think it would be worth stating separat= ely=20 the Objectives of NTS for different modes. And make use of the terms=20 client and server to only refer to NTP's client server mode=20 participants.
In fact the first para of section 1.2 could be used to=20 justify the different objectives of NTS for different modes and could be placed before/in section 1.1

Section 1.2

"it = is harmless for servers to process replayed packets"

I do not agree with the statement above. In addition to Sharon=E2=80=99s=20 objection, in NTS, the server can be DoSd in terms of resources by=20 replaying query packets because it has to do more work than normal NTP.
=
Minor comment: Section 1.2 The last and second to last paras are 2 parts of=20 the same thing. Putting them in 2 points makes it more readable.

= Section 4.

I feel like this section requires more discussion on the length of=20 sessions. Like what is the typical frequency of symmetric peer exchanges and correspondingly what is the typical length of a DTLS session? When=20 will it time out? How often do the peers have to re-establish DTLS=20 session? How do they know? Similar questions for control mode and=20 client/server mode.

Overall, this section needs more explanation.
=E2=80=9CThe two endpoints carry out a DTLS handshake in conformance with Section 3, with the client offering (via an ALPN [RFC7301] extension), and the=20 server accepting, an application-layer protocol of "ntp/4".
Again term client/server is overloaded. This is supposed to be DTLS c= lient and DTLS server and not NTP mode3/4 client server.

Also, add = =E2=80=9CFirst=E2=80=9D in the beginning of sentence.

Section 5
The interpretation of critical bit C seems confusing. How is the figure 2=20 parsed by the client? The interpretation of C is Record Type dependent.
=
Why in section 5.1.5 "C is MAY and not MUST? How is this bit inter= preted when it is 0 or when it is 1?

Also, in section 5.1.6=C2=A0 &q= uot;C SHOULD NOT be set". Again, what does the client do if he finds i= t set?

IMO, this section is very high level description and not very fluent from=20 implementation point of view. As written now, it is very difficult to=20 follow. May be we can have a table with all possible combinations of C=20 and record types and the corresponding action taken by client or the=20 server.

Section 6

=E2=80=9CUpon receiving an=20 NTS-protected response, the client MUST verify that=C2=A0 the Unique=20 Identifier matches =E2=80=A6=E2=80=A6=E2=80=A6 which sent the NAK and initi= ate a fresh NTS-KE=20 handshake.=E2=80=9D

This section is understated and requires muc= h=20 more detailed explanation. The order in which client performs the checks and the corresponding changes it makes to the internal state variables=20 is important to mention as this has lead to several implementation flaws in the past. For instance,

1) If the UID match passes, the client c= hecks for crypto. Then there are two cases:

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a) If crypto is fine, client processes the p= acket and stops listening for any response corresponding to this UID.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b) If crypto fails, it doe= s not process the packet and=20 stops listening for the response corresponding to this UID.

2) If the UID match fails, the client should not check for crypto. AND must=20 still keep listening for the packets corresponding to the stored UID.=20 (Otherwise an easy off-path attack.)

This is just an example.=20 There are several other cases and it is IMPORTANT to mention the state=20 variable changes in EACH case. We should discuss/talk about it and sort=20 this out.

Thanks,
Aanchal Malhotra.
--001a11412da887dc2405586c4623-- --===============7232734198416360266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp --===============7232734198416360266==-- From nobody Fri Sep 8 05:52: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 C9D921321C9 for ; Fri, 8 Sep 2017 05:52:34 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VR0Kl0R9lk1A for ; Fri, 8 Sep 2017 05:52:33 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [IPv6:2001:638:610:bd01::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AF51321A4 for ; Fri, 8 Sep 2017 05:52:32 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v88CqUdS031774-v88CqUdU031774 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Sep 2017 14:52:30 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 5B8835895AA for ; Fri, 8 Sep 2017 14:52:30 +0200 (CEST) To: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Fri, 8 Sep 2017 14:52:28 +0200 Content-Type: multipart/alternative; boundary="=_alternative 0046B97BC1258195_=" Archived-At: Subject: [Ntp] [NTP] REPEAT: Please state a position on NTS advancement (part of: WGLC for draft-ietf-ntp-using-nts-for-ntp) 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: Fri, 08 Sep 2017 12:52:35 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0046B97BC1258195_= Content-Type: text/plain; charset="US-ASCII" Hello all, this is just to echo and re-emphasize the request(s) for position statements regarding the document draft-ietf-ntp-using-nts-for-ntp. I am aware that some, but not all, of you have already gone "on record" with a position statement. Anyone who hasn't yet done so (or who feels that they could do it more explicitly): please do. It would be the most productive (and the most helpful to us editors and the WG co-chairs) to have an explicit overall position statement from as many people in the group as possible. Ideally (one can wish, right?) very clearly along the lines of either - "Yes, advance" (potentially: "after [list of resolvable issues] has been dealt with") - "No, do not advance" (bonus: "because I have insurmountable objections against [list of major issues]") Best regards and have a good weekend, Kristof --=_alternative 0046B97BC1258195_= Content-Type: text/html; charset="US-ASCII" Hello all,

this is just to echo and re-emphasize the request(s) for position statements regarding the document draft-ietf-ntp-using-nts-for-ntp.
I am aware that some, but not all, of you have already gone "on record" with a position statement.
Anyone who hasn't yet done so (or who feels that they could do it more explicitly): please do.

It would be the most productive (and the most helpful to us editors and the WG co-chairs) to have an explicit overall position statement from as many people in the group as possible.
Ideally (one can wish, right?) very clearly along the lines of either
- "Yes, advance"         (potentially: "after [list of resolvable issues] has been dealt with")
- "No, do not advance"         (bonus: "because I have insurmountable objections against [list of major issues]")


Best regards and have a good weekend,
Kristof --=_alternative 0046B97BC1258195_=-- From nobody Sun Sep 10 22:00:33 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 7B6D0129B7A; Sun, 10 Sep 2017 22:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 sb8RmppOmmyN; Sun, 10 Sep 2017 22:00:30 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0074.outbound.protection.outlook.com [104.47.37.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CC912426E; Sun, 10 Sep 2017 22:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GC/aZ5K0ZLTnsjDs6B0qk/ih5mm2No0CkOuKYY9tUSc=; b=kT57DonezmiAytIa1CjPXOjS9JOKEagwBBLphhunc7HgjpWTd1XAFlRRX6bgWqWYLCcxrBRhPdcLisN66Cuehye4pJrxddVB69jUcCbzUuM2C4yXKWaNFWgkOkh3g9GrjS+gES5c0IJLDMusn0cBFBvweXDD6B2hyK4ea+SgDII= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB3174.namprd06.prod.outlook.com (10.171.249.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Mon, 11 Sep 2017 05:00:28 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0035.021; Mon, 11 Sep 2017 05:00:28 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" , "tictoc@ietf.org" Thread-Topic: Virtual interim the week of 25 September Thread-Index: AQHTKrriczipoIsegU6P0OfJzrQ7vg== Date: Mon, 11 Sep 2017 05:00:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB3174; 6:NDzVrhaPF3yld9TaszfVXlwB7QFM7bvPbtgc996WpVcv84hIARAvaYeH88KjAumVkNnio+s7HfPEztW3KlIe50hJPGx0W4Qw19JMB0gjsPiHIzm8S6qJkQhlMfjJ41+voZVAuluWFzDE5Q7mfk0xIp6zV+w2jTtt8eyofunDQhyXCcCabRLPzey7k1O1gRLWVinnKG9Zi4YaTb04239vGyHIPwveVt7gQq+0w0LlRfNgyMVTuHJmBh6y4lqeqnakxY4Koc8N+ozEaK2rCeVCNgCnkPd+c2PTRiCoYkGF+q3AIW80M3pEYHTKjtt3axPo0Se/MrTCiZT2hIo+4irOYg==; 5:ZDRaaTuoJGqD/s+HmazVhdzCvWupzLOsfAzwkpU+t7fzGDSLBwhX4wBttgNYyo3ZYflDoDJs8AvCIUV9squEmiynBF4Wrxl7d9Jq+rcn8kngjIcBR2EwHRN+5nPEGpQzIiGReHUDGPvGOcLRZG3zGw==; 24:3PRSUm3goRHt2061ci4YaiaElJKBwzmXoesFcIGXljfpyOAZovmpboX5sLHqLqRczYauBMDi1H49COYc2eOAGXbxXMy2JbnUpCdTVd/I4xQ=; 7:RwLuHfIYCxNMbThdZbbk5JQM9vQUfkQ2ifyjNHxSG6X/dcRltFwF4FZT7IQHW2Jso8wbiPrpqqiZCGX1QdX9NhadhUP3VxmSPhzxpBHDbR0WGxJAEinxMAdY8CcaLDuFgcgCO8kWah1zL9ae3wvVyazxOD6+uPFvkII6AnsPp59yr2rqcinCXe6S/TgFN7QIsxLxLmffHqGtA3bEIACLEgYy9nEDxeC/l+biKC9ogZs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 061a5627-c682-4b5a-7f9c-08d4f8d20570 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB3174; x-ms-traffictypediagnostic: CY4PR06MB3174: x-exchange-antispam-report-test: UriScan:(60409825278598); 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)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB3174; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB3174; x-forefront-prvs: 04270EF89C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(189002)(199003)(14454004)(450100002)(2501003)(966005)(478600001)(97736004)(606006)(33656002)(2900100001)(5660300001)(105586002)(82746002)(83716003)(25786009)(2906002)(236005)(54896002)(6306002)(99286003)(3660700001)(189998001)(7736002)(3280700002)(6512007)(101416001)(106356001)(6116002)(68736007)(102836003)(3846002)(8936002)(81166006)(81156014)(8676002)(6506006)(53936002)(66066001)(6486002)(77096006)(6436002)(36756003)(54356999)(86362001)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB3174; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B790CC133A44488381207E6EC0850A44isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2017 05:00:28.2599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB3174 Archived-At: Subject: [Ntp] Virtual interim the week of 25 September 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, 11 Sep 2017 05:00:32 -0000 --_000_B790CC133A44488381207E6EC0850A44isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCldlIHBsYW4gdG8gaGF2ZSBhIHZpcnR1YWwgaW50ZXJpbSB0aGUgd2VlayBvZiAy NSBTZXB0ZW1iZXIuIEFmdGVyIGNvbnZlcnNhdGlvbiB3aXRoIERpZXRlciBhbmQgY29uc2lkZXJp bmcgdGhlIHRpbWV6b25lIGRpZmZlcmVuY2VzLCB0aGVyZSBhcmUgbm90IGEgbG90IG9mIG9wdGlv bnMuIE15IHByZWZlcmVuY2UgaXMgdG8gaGF2ZSBhIGNhbGwgb24gVGh1cnNkYXkgMjggU2VwdGVt YmVyIDExOjMwIC0gMTM6MDAgRURUICgxNTozMCAtIDE3OjAwIFVUQykuIEluIGNhc2UgdGhhdCBk b2VzbuKAmXQgd29yaywgSSBoYXZlIHByZXBhcmVkIGEgZG9vZGxlIHBvbGwgZm9yIFdlZCwgVGh1 cnMsIGFuZCBGcmlkYXkgdGhhdCB3ZWVrLiBQbGVhc2UgaW5kaWNhdGUgeW91ciBhdmFpbGFiaWxp dHkgZm9yIGEgbWVldGluZyBkdXJpbmcgb25lIG9mIHRoZXNlIHRocmVlIGRheXMgYnkgQ09CIHRo aXMgVHVlc2RheS4NCg0KaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvN25xc2l6ZjRlYjhmcGN0ZA0K DQpUaGFua3MsDQpLYXJlbg0K --_000_B790CC133A44488381207E6EC0850A44isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRm9sa3MsDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBwbGFuIHRvIGhhdmUgYSB2 aXJ0dWFsIGludGVyaW0gdGhlIHdlZWsgb2YgMjUgU2VwdGVtYmVyLiBBZnRlciBjb252ZXJzYXRp b24gd2l0aCBEaWV0ZXIgYW5kIGNvbnNpZGVyaW5nIHRoZSB0aW1lem9uZSBkaWZmZXJlbmNlcywg dGhlcmUgYXJlIG5vdCBhIGxvdCBvZiBvcHRpb25zLiBNeSBwcmVmZXJlbmNlIGlzIHRvIGhhdmUg YSBjYWxsIG9uIFRodXJzZGF5IDI4IFNlcHRlbWJlciAxMTozMCAtIDEzOjAwIEVEVCAoMTU6MzAN CiAtIDE3OjAwIFVUQykuIEluIGNhc2UgdGhhdCBkb2VzbuKAmXQgd29yaywgSSBoYXZlIHByZXBh cmVkIGEgZG9vZGxlIHBvbGwgZm9yIFdlZCwgVGh1cnMsIGFuZCBGcmlkYXkgdGhhdCB3ZWVrLiBQ bGVhc2UgaW5kaWNhdGUgeW91ciBhdmFpbGFiaWxpdHkgZm9yIGEgbWVldGluZyBkdXJpbmcgb25l IG9mIHRoZXNlIHRocmVlIGRheXMgYnkgQ09CIHRoaXMgVHVlc2RheS48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBz Oi8vZG9vZGxlLmNvbS9wb2xsLzducXNpemY0ZWI4ZnBjdGQiIGNsYXNzPSIiPmh0dHBzOi8vZG9v ZGxlLmNvbS9wb2xsLzducXNpemY0ZWI4ZnBjdGQ8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkthcmVuPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B790CC133A44488381207E6EC0850A44isocorg_-- From nobody Sun Sep 10 22:26: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 990D61321A0 for ; Sun, 10 Sep 2017 22:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 D9E-eafC4bbP for ; Sun, 10 Sep 2017 22:26:21 -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 3EFA313209C for ; Sun, 10 Sep 2017 22:26:21 -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 842CBB87F; Mon, 11 Sep 2017 05:26:20 +0000 (UTC) To: ntp@ietf.org References: From: Harlan Stenn Message-ID: <89f53cd1-1571-d6d6-ddee-5d050f820624@nwtime.org> Date: Sun, 10 Sep 2017 22:26:19 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ntp] Virtual interim the week of 25 September 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, 11 Sep 2017 05:26:22 -0000 What's the agenda for the meeting? H On 9/10/2017 10:00 PM, Karen O'Donoghue wrote: > Folks, > > We plan to have a virtual interim the week of 25 September. After > conversation with Dieter and considering the timezone differences, there > are not a lot of options. My preference is to have a call on Thursday 28 > September 11:30 - 13:00 EDT (15:30 - 17:00 UTC). In case that doesn’t > work, I have prepared a doodle poll for Wed, Thurs, and Friday that > week. Please indicate your availability for a meeting during one of > these three days by COB this Tuesday. > > https://doodle.com/poll/7nqsizf4eb8fpctd > > Thanks, > Karen > > > _______________________________________________ > 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 Wed Sep 13 12:16:21 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 651B013309C; Wed, 13 Sep 2017 12:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 meMsIWff9QrY; Wed, 13 Sep 2017 12:16:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0084.outbound.protection.outlook.com [104.47.34.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648C113309D; Wed, 13 Sep 2017 12:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+0BXM3QqBMKa4jiSNLXo5MlT5YXl8qpUVnvVlFRf1T0=; b=OyQq9ggDlV4SNU0wcS5W82NKgdIyMjC/5MfuWmyCZ31Mzok0JEF+UAMIZAQgrnucs+f0zeX18JiQz1blNhUUmFbW+BMPe9C93rYgn2D9UjU1rorGKqVW8A0Tp7SmyKgprIzNLquuignhxU7yOesTfJw+iRXBcQ+kNtfiCWwJwJA= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2695.namprd06.prod.outlook.com (10.173.40.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Wed, 13 Sep 2017 19:16:02 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0035.021; Wed, 13 Sep 2017 19:16:02 +0000 From: Karen O'Donoghue To: "tictoc@ietf.org" CC: "ntp@ietf.org" Thread-Topic: WGLC for draft-ietf-tictoc-1588v2-yang Thread-Index: AQHTLMS9I02w6VlOokuuR++M6yrZgw== Date: Wed, 13 Sep 2017 19:16:02 +0000 Message-ID: <2D6594B3-2C10-4B65-B789-788A2DBF8E30@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2695; 6:ajK025nfeml+QRydHLKsH0TqiANRytQ5EiXLdzkg5fiWLqCYpbrk0x6iIDj10fa7WLtbm0N36gopPwl61mKfWi57HQIjwknqvid37yQx6OrDZWu2oMYNNd6ArmRmWTLtskThW6pYpw7Bmaq7yGJQudrHgBS1wtlS927/hXHBr87O6BA48bOfJQS9gMCYde5JfoPJmR8QS2ADOlolzn88FvP3/cDav5pmDOWtGRelYYfALIp1mkGG8/jos6y3n5SLrRoP3LD/G86g38M60NKo94rnjAtV02LGO7Q+dDhNmZMuHgeyFXtU8gTRRNZYkCqnWcl+JLJrRaR2Ors9nwa07Q==; 5:fUMHwM/zw1WoXhR98beVggd3go2s0KFKJfmfW1uJmtilXdHDU7/NjmenynB4iMh2avSE0m1KeF265iUlw3TH7+DN6XltWeGiNsoEZ+t0XJKInagzFpE3rJdLievAL3y7KtHmmRrGZSqnMd5/JTl8AA==; 24:6hIIIZ8/ygy3LnoNPAqNAVi64JVsCtPf+de1foJRDQmchlkhFKyB0I8ZxYAOZyekUaGXNzDHrkhK/2NrFdplZw0qoQiHENT3hMHfeb4Ils0=; 7:augKPoKZCCgcD42TmCvAfp+x97eT1pmnAHWpB/j6QwNeCFVZeKnboRCALXWDKyCa69HCGEiBRtznKIqkt2vPiUS0B0acIUCwhp0ZSsptdYe+HLC+euPj62j69jdUNiHD0Lq3wtSIaDfRe2F18MNayM+Z4PQBnGjh/OeFX05jO6eLwgohCoDOi0vRwmoVK8nLoLjZW1vPszea9WAHOOBgV5xZYNt5TV6ox15AwgQhXfE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e655f588-e50f-426a-3473-08d4fadbdfd1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2695; x-ms-traffictypediagnostic: CY4PR06MB2695: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); 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)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2695; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2695; x-forefront-prvs: 042957ACD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39830400002)(346002)(199003)(189002)(3280700002)(450100002)(4326008)(68736007)(36756003)(105586002)(230783001)(5640700003)(83716003)(3660700001)(53936002)(110136004)(6506006)(189998001)(2900100001)(25786009)(6436002)(77096006)(966005)(106356001)(101416001)(99286003)(478600001)(6512007)(6306002)(86362001)(2351001)(6486002)(6916009)(5660300001)(8936002)(316002)(2906002)(54356999)(97736004)(50986999)(33656002)(81156014)(8676002)(1730700003)(7736002)(82746002)(81166006)(66066001)(3846002)(14454004)(305945005)(2501003)(102836003)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2695; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2017 19:16:02.4018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2695 Archived-At: Subject: [Ntp] WGLC for draft-ietf-tictoc-1588v2-yang 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, 13 Sep 2017 19:16:13 -0000 Folks, This message begins a 2 week working group last call (WGLC) for the followi= ng document:=20 YANG Data Model for IEEE 1588v2 https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/ Please review the referenced document and send any comments to the mailing = list including your assessment of whether this document is mature enough to= proceed to the IESG. Please note that these messages of support for progre= ssion to the mailing list are important and will be used to determine WG co= nsensus to proceed.=20 Please send all comments in by Thursday 28 September 2017. =20 Thank you! Karen= From nobody Wed Sep 13 13:10:15 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 2B942132EE2; Wed, 13 Sep 2017 13:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 YatcVL0m1K4B; Wed, 13 Sep 2017 13:10:02 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0079.outbound.protection.outlook.com [104.47.34.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD736132ED2; Wed, 13 Sep 2017 13:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JQr1JoFtS1X7Ri7ADecHOSaVeqK5xbjB/TBM03SaYGk=; b=FjngavRsk9XYAuRtr0bYAtsRf/hikClx4cel+Xm+HArTF9TvCmVgZKKk5haV0yiroXUnWcbiL4Gg6eMTxZ30KwhIHgVumLDMOZEGCJw4XUIGyZ020kSXeBZmdxxjoyX9ne9jwbvLugxjhtjXDamamnQD9EptaxNfH3pnluEkRc8= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2918.namprd06.prod.outlook.com (10.175.118.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Wed, 13 Sep 2017 20:10:00 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0035.021; Wed, 13 Sep 2017 20:10:00 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" , "tictoc@ietf.org" CC: "iesg-secretary@ietf.org" Thread-Topic: Joint NTP and TICTOC WGs virtual interim (Friday, 29 September, 1530-1700 UTC) Thread-Index: AQHTLMxH3/bKdBkt00qrjFOsr9jZlg== Date: Wed, 13 Sep 2017 20:10:00 +0000 Message-ID: <6C05DFDC-9F99-41E2-A6C0-5FD2078F7799@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2918; 6:g5Hd/0medRhCbMxbrndK51sz1cxRT8ETTTduaXyrDNsjs+G9RQraKm9OjlMeUKesgnl2DdZ0F6Fpc/U7A+/sAW1+Vg69b4vcINY4R+4lBrWlvy0qP8d4roBS+7dEU89uLTQggBhVQVGyERkahFcGbr/d6cRYXNwbI9jBbwxayUhOpdPliPV8HS3hmJYrLLdcUm9qQHjQo+bzq1TkIcONhne1+PFXupNgBZNdkW9jX1U9wEK/ECMwNzRFxIrxXrbwuafjfjSGJpJlHEpWIEYD7TjyGnRsXnj3Dv3LayEonyP1rQykmgVDkPMozNb/3r4GXuMviHSrAD8l5h1AkyH/Wg==; 5:gP2z36SsWF+RBkDjIyaA++VrQuqa5E8rAQk11dv0RegeyUREUm0cYeiQDatznBbwQgyunMwI1bRdiVOejkpVuC/9q4w20Rls8tW4iO4ERcgDb3zzbNg/3fowf+YwKXdlb3UmKtyaOAv7CGuN3KL+Hw==; 24:UqbqkelswT5Sa1UVxXvhMM5lbrejU8w1oa3Rj9U8tJv3u4wHk1BvBuRY32PXpWIT8mv/JMM4dnU3nFg75HHJzi2DwUfaZkQVLDH4S5ka5AM=; 7:/nY21y7zY8hpk1d7Md1GnJ02CUsrbz1D5NCfe3MGQmyDaCZhqoyYhUhdtPQl6PuNlZq1M5GO5AxpCKz8SgJE/xEJqHsTX4RFgBv0FjO4qaRKl2OTt62D6j/1mINXfDhhGCzf1OZO0MWys64yPYiYquL8Hrt8Zz25FCnoxGDnAHQjiOggd1gsKAZM8WdsEXYXogMkeLrw9wOs/4deL3tIRAUzm/xOwr8b5pQdhRfzZW8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f26c02ae-763e-498c-8d86-08d4fae369c9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2918; x-ms-traffictypediagnostic: CY4PR06MB2918: x-exchange-antispam-report-test: UriScan:(120809045254105)(257447070540367); 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)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2918; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2918; x-forefront-prvs: 042957ACD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(346002)(376002)(189002)(377454003)(199003)(497574002)(6486002)(77096006)(83716003)(14454004)(4743002)(478600001)(8936002)(81156014)(6506006)(3846002)(33656002)(97736004)(54896002)(6436002)(6306002)(2501003)(6116002)(99286003)(36756003)(66066001)(966005)(4326008)(450100002)(81166006)(102836003)(8676002)(25786009)(82746002)(3660700001)(236005)(7736002)(53936002)(3280700002)(606006)(6512007)(54356999)(86362001)(316002)(2906002)(50986999)(5660300001)(189998001)(105586002)(106356001)(68736007)(2900100001)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2918; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6C05DFDC9F9941E2A6C05FD2078F7799isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2017 20:10:00.4325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2918 Archived-At: Subject: [Ntp] Joint NTP and TICTOC WGs virtual interim (Friday, 29 September, 1530-1700 UTC) 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, 13 Sep 2017 20:10:06 -0000 --_000_6C05DFDC9F9941E2A6C05FD2078F7799isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNClRoZXJlIHdpbGwgYmUgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBvZiB0aGUg SUVURiBOVFAvVElDVE9DIHdvcmtpbmcgZ3JvdXBzIG9uIEZyaWRheSAyOSBTZXB0ZW1iZXIgMjAx NyAoMTUzMCAtIDE3MDAgVVRDKS4gVGhlIGRyYWZ0IGFnZW5kYSBhbmQgem9vbSBjb29yZGluYXRl cyBhcmUgcHJvdmlkZWQgYmVsb3cuIFBsZWFzZSBub3RlIHRoYXQgcHJpb3JpdHkgd2lsbCBiZSBn aXZlbiB0byBkaXNjdXNzaW9uIG9mIFdHTEMgY29tbWVudHMgZHVyaW5nIHRoaXMgbWVldGluZy4N Cg0KUmVnYXJkcywNCkthcmVuDQoNCg0KRHJhZnQgQWdlbmRhOg0KPT09PT09PT09PT0NCg0KMS4g V0dMQyBjb21tZW50IHJlc29sdXRpb24gYW5kIHdheSBmb3J3YXJkIGZvciBNQUMgdXBkYXRlIGZv ciBOVFANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLW1h Yy8NCg0KMi4gV0dMQyBjb21tZW50IHJlc29sdXRpb24gYW5kIHdheSBmb3J3YXJkIGZvciBOVFMg Zm9yIE5UUA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAt dXNpbmctbnRzLWZvci1udHAvDQoNCjMuIE5UUCBFeHRlbnNpb24gZmllbGRzDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdGVubi1udHAtZXh0ZW5zaW9uLWZpZWxkcy8N Cg0KNC4gTlRQIENvbnRyb2wgbWVzc2FnZXMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbnRwLW1vZGUtNi1jbWRzLw0KDQo1LiBOVFAgRGF0YSBtaW5pbWl6YXRp b24NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLWRhdGEt bWluaW1pemF0aW9uLw0KDQo2LiBXR0xDIGZvciBZQU5HIERhdGEgTW9kZWwgZm9yIElFRUUgMTU4 OHYyDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRpY3RvYy0x NTg4djIteWFuZy8NCg0KNy4gSUVFRSAxNTg4IEVudGVycHJpc2UgUHJvZmlsZQ0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10aWN0b2MtcHRwLWVudGVycHJpc2Ut cHJvZmlsZS8NCg0KOC4gTm90IG9uIHRoZSBhZ2VuZGEgdG9kYXkgYnV0IG5vdCBmb3Jnb3R0ZW4N Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLWJjcC8NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLXlhbmctZGF0YS1t b2RlbC8NCg0KOS4gQU9CDQoNCioqKioqKioqKioqIENhbGwgaW4gZGV0YWlscy4gKioqKioqKioq KioNCg0KVG9waWM6IElFVEYgTlRQL1RJQ1RPQyB2aXJ0dWFsIGludGVyaW0gbWVldGluZw0KVGlt ZTogU2VwIDI5LCAyMDE3IDExOjMwIEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZSAoVVMgYW5kIENh bmFkYSkNCg0KSm9pbiBmcm9tIFBDLCBNYWMsIExpbnV4LCBpT1Mgb3IgQW5kcm9pZDogaHR0cHM6 Ly9pc29jLnpvb20udXMvai84MDE0NDM5OTkNCg0KT3IgaVBob25lIG9uZS10YXAgOg0KICAgIFVT OiArMTY0NjU1ODg2NTYsLDgwMTQ0Mzk5OSMgIG9yICsxNjY5OTAwNjgzMywsODAxNDQzOTk5Iw0K T3IgVGVsZXBob25l77yaDQogICAgRGlhbChmb3IgaGlnaGVyIHF1YWxpdHksIGRpYWwgYSBudW1i ZXIgYmFzZWQgb24geW91ciBjdXJyZW50IGxvY2F0aW9uKe+8mg0KICAgICAgICBVUzogKzEgNjQ2 IDU1OCA4NjU2ICBvciArMSA2NjkgOTAwIDY4MzMNCiAgICBNZWV0aW5nIElEOiA4MDEgNDQzIDk5 OQ0KICAgIEludGVybmF0aW9uYWwgbnVtYmVycyBhdmFpbGFibGU6IGh0dHBzOi8vaXNvYy56b29t LnVzL3pvb21jb25mZXJlbmNlP209MlZmQlktSVJzbmVQNDU5aGpWMjF2N01vMld5VzJnckoNCg0K T3IgYW4gSC4zMjMvU0lQIHJvb20gc3lzdGVtOg0KICAgIEguMzIzOg0KICAgICAgICAxNjIuMjU1 LjM3LjExIChVUyBXZXN0KQ0KICAgICAgICAxNjIuMjU1LjM2LjExIChVUyBFYXN0KQ0KICAgICAg ICAyMjEuMTIyLjg4LjE5NSAoQ2hpbmEpDQogICAgICAgIDExNS4xMTQuMTMxLjcgKEluZGlhKQ0K ICAgICAgICAyMTMuMTkuMTQ0LjExMCAoRU1FQSkNCiAgICAgICAgMjAyLjE3Ny4yMDcuMTU4IChB dXN0cmFsaWEpDQogICAgICAgIDIwOS45LjIxMS4xMTAgKEhvbmcgS29uZykNCiAgICAgICAgNjQu MjExLjE0NC4xNjAgKEJyYXppbCkNCiAgICBNZWV0aW5nIElEOiA4MDEgNDQzIDk5OQ0KDQogICAg U0lQOiA4MDE0NDM5OTlAem9vbWNyYy5jb208bWFpbHRvOjgwMTQ0Mzk5OUB6b29tY3JjLmNvbT4N Cg0K --_000_6C05DFDC9F9941E2A6C05FD2078F7799isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <601E785AA2A3A746B5FA88C31C034FC5@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Gb2xrcyw8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlcmUgd2lsbCBiZSBhIHZpcnR1YWwg aW50ZXJpbSBtZWV0aW5nIG9mIHRoZSBJRVRGIE5UUC9USUNUT0Mgd29ya2luZyBncm91cHMgb24g RnJpZGF5IDI5IFNlcHRlbWJlciAyMDE3ICgxNTMwIC0gMTcwMCBVVEMpLiBUaGUgZHJhZnQgYWdl bmRhIGFuZCB6b29tIGNvb3JkaW5hdGVzIGFyZSBwcm92aWRlZCBiZWxvdy4gUGxlYXNlIG5vdGUg dGhhdCBwcmlvcml0eSB3aWxsIGJlIGdpdmVuIHRvIGRpc2N1c3Npb24gb2YgV0dMQw0KIGNvbW1l bnRzIGR1cmluZyB0aGlzIG1lZXRpbmcuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5LYXJlbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48YiBjbGFzcz0iIj5EcmFmdCBBZ2VuZGE6Jm5ic3A7PC9iPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj49PT09PT09PT09PTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4gV0dMQyBjb21tZW50IHJlc29sdXRpb24gYW5kIHdheSBm b3J3YXJkIGZvciBNQUMgdXBkYXRlIGZvciBOVFAmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAt bWFjLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1udHAtbWFjLzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjIuIFdHTEMgY29tbWVudCByZXNvbHV0aW9uIGFuZCB3YXkgZm9yd2Fy ZCBmb3IgTlRTIGZvciBOVFA8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAtdXNpbmctbnRzLWZvci1udHAv IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50 cC11c2luZy1udHMtZm9yLW50cC88L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4zLiBOVFAgRXh0ZW5zaW9uIGZpZWxkczwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1zdGVubi1udHAtZXh0ZW5zaW9uLWZpZWxkcy8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN0ZW5uLW50cC1leHRlbnNpb24tZmllbGRzLzwvYT48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjQuIE5UUCBDb250cm9sIG1lc3NhZ2VzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLW1vZGUtNi1jbWRz LyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1u dHAtbW9kZS02LWNtZHMvPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+NS4gTlRQIERhdGEgbWluaW1pemF0aW9uPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbnRwLWRhdGEtbWluaW1pemF0aW9uLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAtZGF0YS1taW5pbWl6YXRpb24vPC9hPjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ni4g V0dMQyBmb3IgWUFORyBEYXRhIE1vZGVsIGZvciBJRUVFIDE1ODh2MjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LXRpY3RvYy0xNTg4djIteWFuZy8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLzwvYT48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjcuIElFRUUgMTU4OCBF bnRlcnByaXNlIFByb2ZpbGUmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10aWN0b2MtcHRwLWVudGVy cHJpc2UtcHJvZmlsZS8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtdGljdG9jLXB0cC1lbnRlcnByaXNlLXByb2ZpbGUvPC9hPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+OC4gTm90IG9u IHRoZSBhZ2VuZGEgdG9kYXkgYnV0IG5vdCBmb3Jnb3R0ZW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAt YmNwLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1udHAtYmNwLzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAteWFuZy1kYXRhLW1vZGVsLyIgY2xh c3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAteWFu Zy1kYXRhLW1vZGVsLzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjkuIEFPQiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGIgY2xhc3M9IiI+KioqKioqKioqKiogQ2FsbCBpbiBkZXRhaWxzLiAqKioqKioqKioqKjwvYj48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlRvcGljOiBJRVRGIE5UUC9USUNUT0MgdmlydHVhbCBpbnRlcmltIG1lZXRpbmc8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGltZTogU2VwIDI5LCAyMDE3IDExOjMwIEFNIEVhc3Rlcm4gU3RhbmRhcmQg VGltZSAoVVMgYW5kIENhbmFkYSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkpvaW4gZnJvbSBQQywgTWFjLCBMaW51eCwgaU9TIG9yIEFu ZHJvaWQ6IDxhIGhyZWY9Imh0dHBzOi8vaXNvYy56b29tLnVzL2ovODAxNDQzOTk5IiBjbGFzcz0i Ij4NCmh0dHBzOi8vaXNvYy56b29tLnVzL2ovODAxNDQzOTk5PC9hPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+T3IgaVBob25lIG9uZS10 YXAgOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IFVTOiAmIzQzOzE2NDY1NTg4 NjU2LCw4MDE0NDM5OTkjICZuYnNwO29yICYjNDM7MTY2OTkwMDY4MzMsLDgwMTQ0Mzk5OSMmbmJz cDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+T3IgVGVsZXBob25l77yaPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPiZuYnNwOyAmbmJzcDsgRGlhbChmb3IgaGlnaGVyIHF1YWxpdHksIGRpYWwgYSBudW1iZXIg YmFzZWQgb24geW91ciBjdXJyZW50IGxvY2F0aW9uKe+8mjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVVM6ICYjNDM7MSA2NDYgNTU4IDg2NTYgJm5ic3A7 b3IgJiM0MzsxIDY2OSA5MDAgNjgzMyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7IE1lZXRpbmcgSUQ6IDgwMSA0NDMgOTk5PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw OyAmbmJzcDsgSW50ZXJuYXRpb25hbCBudW1iZXJzIGF2YWlsYWJsZTogPGEgaHJlZj0iaHR0cHM6 Ly9pc29jLnpvb20udXMvem9vbWNvbmZlcmVuY2U/bT0yVmZCWS1JUnNuZVA0NTloalYyMXY3TW8y V3lXMmdySiIgY2xhc3M9IiI+DQpodHRwczovL2lzb2Muem9vbS51cy96b29tY29uZmVyZW5jZT9t PTJWZkJZLUlSc25lUDQ1OWhqVjIxdjdNbzJXeVcyZ3JKPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+T3IgYW4gSC4zMjMvU0lQIHJv b20gc3lzdGVtOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IEguMzIzOiZuYnNw OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTYyLjI1 NS4zNy4xMSAoVVMgV2VzdCk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDE2Mi4yNTUuMzYuMTEgKFVTIEVhc3QpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyMjEuMTIyLjg4LjE5NSAoQ2hpbmEpPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxMTUuMTE0LjEzMS43IChJ bmRpYSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIx My4xOS4xNDQuMTEwIChFTUVBKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgMjAyLjE3Ny4yMDcuMTU4IChBdXN0cmFsaWEpPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyMDkuOS4yMTEuMTEwIChIb25nIEtvbmcp PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA2NC4yMTEu MTQ0LjE2MCAoQnJhemlsKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IE1lZXRp bmcgSUQ6IDgwMSA0NDMgOTk5PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IFNJUDogPGEgaHJlZj0ibWFpbHRvOjgw MTQ0Mzk5OUB6b29tY3JjLmNvbSIgY2xhc3M9IiI+ODAxNDQzOTk5QHpvb21jcmMuY29tPC9hPjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_6C05DFDC9F9941E2A6C05FD2078F7799isocorg_-- From nobody Wed Sep 13 19:12:47 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 D23341326BB for ; Wed, 13 Sep 2017 19:12:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 086Yp8NDIEkh for ; Wed, 13 Sep 2017 19:12:42 -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 027E31323A3 for ; Wed, 13 Sep 2017 19:12:41 -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 44366B836; Thu, 14 Sep 2017 02:12:40 +0000 (UTC) To: "ntp@ietf.org" From: Harlan Stenn Message-ID: <4d249b7a-3f61-3183-749a-d05832fed0ec@nwtime.org> Date: Wed, 13 Sep 2017 19:12:39 -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: multipart/mixed; boundary="------------D5942FFE712D6E4ED125EDB3" Content-Language: en-US Archived-At: Subject: [Ntp] Dave's latest Autokey document 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: Thu, 14 Sep 2017 02:12:46 -0000 This is a multi-part message in MIME format. --------------D5942FFE712D6E4ED125EDB3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit -- Harlan Stenn http://networktimefoundation.org - be a member! --------------D5942FFE712D6E4ED125EDB3 Content-Type: text/plain; charset=UTF-8; name="Autokey3.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Autokey3.txt" 77u/RW5naW5lZXJpbmcgYW5kIFNlY3VyaXR5IGZvciB0aGUgTmV0d29yayBUaW1lIFByb3Rv Y29sIChOVFApDQpEYXZpZCBMLiBNaWxscw0KSGFybGFuIFN0ZW5uDQoxMyBTZXB0ZW1iZXIg MjAxNw0KDQpBYnN0cmFjdA0KDQpUaGlzIGRvY3VtZW50IGV4cGxvcmVzIHRoZSBzZWN1cml0 eSBhcmNoaXRlY3R1cmUgYW5kIHByb3RvY29scyBmb3IgdGhlIHRoZSBuZXR3b3JrIHRpbWUg cHJvdG9jb2wgTlRQLiBJdCBwcm9wb3NlcyBhIHNldCBvZiBlbmdpbmVlcmluZyBwcmluY2lw bGVzIGJhc2VkIG9uIFJGQzU5MDUsIGFsb25nIHdpdGggYSByZWRlc2lnbiBvZiB0aGUgQXV0 b2tleSBzY2hlbWUgZGVzY3JpYmVkIGluIFJGQzU5MDYuDQoNClRoZSBuZXcgcHJvdG9jb2wg aXMgbW9yZSByZXNpc3RhbnQgdG8gcHJvdG9jb2wgZXJyb3JzIGFuZCBrZXkgcmVwbGFjZW1l bnQuIFRoZSBwcm90b2NvbCBpbnZvbHZlcyB2YXJpb3VzIGFncmVlbWVudCBhbmQgc2lnbmF0 dXJlIGFsZ29yaXRobXMgbGVhZGluZyB0byBhIHNlY3VyZSBtZWFucyBmb3IgcHJvdGVjdGlu ZyBOVFAgZnJvbSB3aXJldGFwIGFuZCBtaWRkbGVtYW4gYXR0YWNrLiBUaGUgbmV3IHByb3Rv Y29sIGhhcyB0d28gYWR2YW50YWdlczogYSBjb21wYWN0IHNpZ25hdHVyZSB0cmFpbCB0aGF0 IGF2b2lkcyBhIGNlcnRpZmljYXRlIGNhY2hlIGFuZCBhIGhhc2ggc2NoZW1lIHRoYXQgd29y a3MgZm9yIGFsbCBwYWNrZXRzLCBpbmNsdWRpbmcgdGhlIGhhbmRzaGFrZSBwYWNrZXRzLg0K DQoxLiBJbnRyb2R1Y3Rpb24NCg0KUmVjZW50IGludGVybmV0IGRyYWZ0cyBoYXZlIGRlc2Ny aWJlZCBhIHNlY3VyaXR5IGFyY2hpdGVjdHVyZSBtb2RlbCB0b2dldGhlciB3aXRoIGl0cyBh cHBsaWNhdGlvbiB0byBOVFAuIFRoaXMgbW9kZWwsIHdoaWxlIHRlY2huaWNhbGx5IHNvdW5k LCBoYXMgc2lnbmlmaWNhbnQgcHJvYmxlbXMgd2l0aCB0aGUgY3VycmVudCBOVFAgYXJjaGl0 ZWN0dXJlIG1vZGVsIGFzIGRlc2NyaWJlZCBpbiBSRkM1OTA1LiBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBob3cgYW5kIHdoeSB0aGUgdHdvIGFyY2hpdGVjdHVyZSBtb2RlbHMgZGlmZmVy IGFuZCBob3cgY2VydGFpbiBjaGFuZ2VzIG1pZ2h0IG1pdGlnYXRlIHRoZXNlIHByb2JsZW1z Lg0KDQpPbmUgb2YgdGhlIG1vc3QgaW1wb3J0YW50IGlzc3VlcyBkdXJpbmcgdGhlIHR3byBk ZWNhZGVzIG9mIE5UUCBzZWN1cml0eSBkZXZlbG9wbWVudCBoYXMgYmVlbiB0byBkZXNpZ24g dGhlIHNlY3VyaXR5IG1lYW5zIGFzIGFuIGludGVncmF0ZWQgc3lzdGVtLiBUaGlzIGludm9s dmVzIGNhcmVmdWwgaW50ZWdyYXRpb24gIG9mIHByb3RvY29sIGRlc2lnbiwgc2VjdXJpdHkg bWVhbnMgYW5kIGVycm9yIHJlY292ZXJ5LiBFdmVyeXRoaW5nIGRlcGVuZHMgb24gZXZlcnl0 aGluZyBlbHNlLCBhbmQgYSB0aW55IGNoYW5nZSBtYXkgaGF2ZSB1bmludGVuZGVkIGNvbnNl cXVlbmNlcy4NCg0KVGhpcyBkb2N1bWVudCBhdHRlbXB0cyB0byBjb250aW51ZSB0aGUgZXZv bHV0aW9uIG9mIHRoZSBOVFAgc2VjdXJpdHkgbW9kZWwuIEl0IG1heSBiZSB0aGF0IGxlc3Nv bnMgaW4gdGhpcyBkb2N1bWVudCBhcmUgbm90IHVzZWZ1bCB0byB0aGUgTlRQIG5ldHdvcmtp bmcgY29tbXVuaXR5LCBidXQgaW4gYW55IGNhc2UgdGhleSBjYW4gYmUgdXNlZnVsIGFzIGEg c2FuaXR5IGNoZWNrLg0KDQpJbiBhZGRpdGlvbiwgdGhlIEF1dG9rZXkgcHVibGljIGtleSBz ZWN1cml0eSBzY2hlbWUgZGVzY3JpYmVkIGluIFJGQzU5MDYgd2FzIGRlc2lnbmVkIGFuZCBp bXBsZW1lbnRlZCBvdmVyIHR3ZW50eSB5ZWFycyBhZ28uIFRpbWUgYW5kIE1vb3JlJ3MgbGF3 IGhhdmUgY2F1Z2h0IHVwIHRvIGl0LiBCYWNrIHRoZW4sIGl0IHRvb2sgb3ZlciBvbmUgc2Vj b25kIHRvIGNhbGN1bGF0ZSBhIHB1YmxpYyBrZXkgc2lnbmF0dXJlLiBUb2RheSwgaXQgdGFr ZXMgb25seSBhIG1pbGxpc2Vjb25kIG9yIHR3by4NCg0KVGhpcyBkb2N1bWVudCBvdXRsaW5l cyBhIHByb3Bvc2VkIHJlcGxhY2VtZW50IGZvciBBdXRva2V5LiBUaGUgc2NoZW1lIHByb3Bv c2VkIGhlcmUgaXMgaXMgYmFzZWQgb24gdGhlIERpZmZpZS1IZWxsbWFuIGFncmVlbWVudCBh bGdvcml0aG0sIHdoaWNoIHJlc3VsdHMgaW4gYW4gZWNvbm9taWNhbCBpbXBsZW1lbnRhdGlv biBhbmQgbG93IHJ1bm5pbmcgdGltZS4gVGhpcyBkb2N1bWVudCBzdWdnZXN0cyBhIHZhcmlh bnQgb2YgdGhpcyBhbGdvcml0aG0gcG9wdWxhcmx5IGtub3duIGFzIHRoZSBTdGF0aW9uIHRv IFN0YXRpb24gUHJvdG9jb2wuDQoNCkF1dG9rZXkgaW4gaXRzIHByZXNlbnQgZm9ybSBpcyBh biBvcHRpb25hbCBmZWF0dXJlIG9mIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24uIElu IGZhY3QsIHRoZSBzaWduaWZpY2FudCBwcm9wb3NlZCBjaGFuZ2VzIGluIHRoaXMgZG9jdW1l bnQgYXJlIHRvIHRoZSBwdWJsaWMga2V5IGxheWVyLiBUaGUgb3RoZXIgcHJvdG9jb2wgbGF5 ZXJzIGluIHRoZSBkZXNpZ24sIGluY2x1ZGluZyB0aGUgZm9ybWF0LCBzeW1tZXRyaWMga2V5 IGFuZCBvbi13aXJlIGxheWVycywgYXJlIHN1YnN0YW50aWFsbHkgdW5jaGFuZ2VkLiBUaGUg c2NoZW1lIGFwcGVhcnMgYXMgYW4gYWdyZWVtZW50IGFsZ29yaXRobSBwYXJhc2l0aWMgb24g dGhlIG9uLXdpcmUgbGF5ZXIuIEl0IGRpc2FwcGVhcnMgd2hlbiBpdHMgZnVuY3Rpb24gaXMg YWNjb21wbGlzaGVkLg0KDQpUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBlbmdpbmVlcmluZyBp c3N1ZXMgaW1wb3J0YW50IHRvIHRoZSBzZWN1cml0eSBkZXNpZ24uIEl0IGRvZXMgbm90IGRp c2N1c3MgcGFja2V0IGZvcm1hdHMsIGN1cnJlbnQgYW5kIHByb3Bvc2VkIE5UUCBleHRlbnNp b24gZmllbGQgZm9ybWF0cywgb3Igc3VwcG9ydGluZyBrZXkgZ2VuZXJhdGlvbiBvciBkaXN0 cmlidXRpb24uDQoNCjIuIFByb3RvY29sIEJhc2ljcw0KDQpGb3IgdGhlIHB1cnBvc2VzIG9m IHRoaXMgZG9jdW1lbnQsIGEgcHJvdG9jb2wgZGF0YSB1bml0IChQRFUpIGlzIGFuIE5UUCBl eHRlbnNpb24gZmllbGQsIHNvbWV0aW1lcyBjYWxsZWQgYSBtZXNzYWdlLiBPbmUgb3IgbW9y ZSBtZXNzYWdlcyBjYW4gYmUgYXBwZW5kZWQgdG8gYW4gTlRQIHBhY2tldCBoZWFkZXIuIEVh Y2ggbWVzc2FnZSBjb25zaXN0cyBvZiBhIGZ1bmN0aW9uIG9jdGV0LCBtb2RpZmllciBvY3Rl dCwgdHdvIG9jdGV0IGRhdGEgbGVuZ3RoLCBhbmQgZm9sbG93ZWQgYnkgdGhlIGRhdGEgaXRz ZWxmLCB6ZXJvIHBhZGRlZCB0byBhIGZvdXIgb2N0ZXQgYm91bmRhcnkuDQoNCk5UUCBwYWNr ZXRzIGFyZSB0cmFuc21pdHRlZCBhdCBpbnRlcnZhbHMgYWNjb3JkaW5nIHRvIHRoZSBOVFAg b24td2lyZSBwcm90b2NvbC4gIFNpbmNlIHRoZSBleHRlbnNpb24gZmllbGRzIHBpZ2d5YmFj ayBvbiB0aGVzZSBwYWNrZXRzLCB0aGUgc2VjdXJpdHkgcHJvdG9jb2wgaXMgY29uc3RyYWlu ZWQgdG8gdGhlc2UgaW50ZXJ2YWxzLg0KDQoyLjEgTWVzc2FnZSBTaXplDQoNCkl0IGlzIGNv bnZlbmllbnQgdG8gcmVzdHJpY3QgdGhlIG1heGltdW0gbWVzc2FnZSBzaXplIHRvIHNvbWUg cmVhc29uYWJsZSB2YWx1ZSBpbiB0aGUgb3JkZXIgb2YgMjU2IG9jdGV0cy4gIHRoaXMgaXMg dGhlIHNpemUgb2YgYSBwdWJsaWMga2V5LCBzaWduYXR1cmUsIHBhcmFtZXRlciB2ZWN0b3Ig b3IgZW5jcnlwdGVkIGNvb2tpZS4gYSBjZXJ0aWZpY2F0ZSBpcyB0d2ljZSB0aGlzIHNpemUs IGluY2x1ZGluZyBhIHB1YmxpYyBrZXkgYW5kIGl0cyBzaWduYXR1cmUuDQoNCk9ubHkgb25l IHBhY2tldCBpbiB0aGUgcHJvdG9jb2wgZGVzY3JpYmVkIGhlcmUgaGFzIG1vcmUgdGhhbiBv bmUgbWVzc2FnZSBhbmQgdGhhdCBvbmUgaGFzIG9ubHkgdHdvIG1lc3NhZ2VzLiAgVGhlIG1h eGltdW0gdG90YWwgcGFja2V0IHNpemUsIGluY2x1ZGluZyB0aGUgTlRQIGhlYWRlciBwbHVz IGFsbCBtZXNzYWdlcyBtdXN0IGJlIGxlc3MgdGhhbiB0aGUgTVRVIG9mIDE1MDAgb2N0ZXRz Lg0KDQoyLjIgTWVzc2FnZSBTdHJ1Y3R1cmUNCg0KT3JkaW5hcmlseSwgdGhlIGZ1bmN0aW9u IG9jdGV0IGZvciBib3RoIHRoZSByZXF1ZXN0cyBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgaXMg dGhlIHNhbWUuLCBleGNlcHQgZm9yIGEgcmVzcG9uc2UgaW5kaWNhdG9yIGJpdC4gVGhlIHJl c3BvbnNlIGluZGljYXRvciBiaXQgaXMgc2V0IHRvIHplcm8gZm9yIGEgcmVxdWVzdCBtZXNz YWdlIGFuZCB0byBvbmUgZm9yIHRoZSBhc3NvY2lhdGVkIHJlc3BvbnNlIG1lc3NhZ2UuIE11 bHRpcGxlIG1lc3NhZ2VzIGNhbiBiZSBzcGxpdCBvdmVyIG11bHRpcGxlIE5UUCBwYWNrZXRz IGFzIG5lY2Vzc2FyeSwgZHVlIHRvIHBhY2tldCBsZW5ndGggcmVzdHJpY3Rpb25zLiBNdWx0 aXBsZSByZXNwb25zZXMgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHNpbmdsZSByZXF1ZXN0 Lg0KDQpJZiBhIHRpbWVvdXQgb2NjdXJzIGJlZm9yZSByZWNlaXZpbmcgYSByZXNwb25zZSB0 byBhIHByZXZpb3VzIHJlcXVlc3QsIHRoZSByZXF1ZXN0IGlzIHNlbnQgYWdhaW4gd2l0aCBu ZXcgc3RhdGUgdmFyaWFibGVzIGluIHRoZSBuZXh0IE5UUCBwYWNrZXQuIEEgcmVzcG9uc2Ug d2l0aG91dCBhIHByZXZpb3VzIG1hdGNoaW5nIHJlcXVlc3QgaXMgZGlzY2FyZGVkLiBJZiBh IHJlcXVlc3QgaXMgcmVjZWl2ZWQgYmVmb3JlIHRoZSByZXNwb25zZSB0byBhIHByZXZpb3Vz IHJlcXVlc3QsIHRoZSByZXN1bHQgaXMgYSBwcm90b2NvbCBlcnJvci4NCg0KT25jZSB0aGUg cHJvdG9jb2wgZGFuY2VzIGhhdmUgbGVmdCB0aGUgc3RhZ2UsIHRoZSByZXN1bHQgaXMgYSBz aGFyZWQgaGFzaCBrZXkuIFRoZSBoYXNoIGtleSBpcyB1c2VkIHRvIGF1dGhlbnRpY2F0ZSBl YWNoIHBhY2tldCB1c2luZyBhIHNlbGVjdGVkIGhhc2ggYWxnb3JpdGhtLg0KDQoyLjMgTWVz c2FnZSBFeGNoYW5nZXMNCg0KQW4gZXhjaGFuZ2UgaXMgYSB2b2xsZXkgY29uc2lzdGluZyBv ZiBhIHNpbmdsZSByZXF1ZXN0IG1lc3NhZ2UgdG8gYSBob3N0IGZvbGxvd2VkIGJ5IG9uZSBv ciBtb3JlIHJlc3BvbnNlIG1lc3NhZ2VzIGZyb20gdGhhdCBob3N0LiBJbiBnZW5lcmFsLCBl YWNoIGV4Y2hhbmdlIHBlcmZvcm1zIGEgc2luZ2xlIGZ1bmN0aW9uIGluZGVwZW5kZW50IG9m IG90aGVyIGV4Y2hhbmdlcy4NCg0KMy4gQmFja3dhcmQgQ29tcGF0aWJpbGl0eQ0KDQpJdCBp cyBpbXBvcnRhbnQgdGhhdCB0aGUgY3VycmVudCBjcnlwdG9ncmFwaGljIGtleXMgbW9kZWwg YW5kIHRoZSBOVFAgbW9kZXMsIGluY2x1ZGluZyBjbGllbnQvc2VydmVyLCBzeW1tZXRyaWMs IGJyb2FkY2FzdC9tdWx0aWNhc3QvbWFueWNhc3QgYW5kIGludGVybGVhdmUgbW9kZXMsIGJl IHByZXNlcnZlZC4gVGhlIGV4aXN0aW5nIHN5bW1ldHJpYyBrZXkgZGVzaWduLCBpbmNsdWRp bmcgdGhlIGtleXMgZmlsZSwgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlIChNQUMpIGZv cm1hdCBhbmQgc2VsZWN0aW9uIG9mIGhhc2ggYWxnb3JpdGhtLHNob3VsZCBhbHNvIGJlIHJl dGFpbmVkLiBJdCBpcyBub3QgbmVjZXNzYXJ5IHRvIHByZXNlcnZlIHRoZSBjdXJyZW50IEF1 dG9rZXkgc2NoZW1lIGl0c2VsZiwgYWx0aG91Z2ggc29tZSBlbGVtZW50cyBvZiB0aGlzIHNj aGVtZSByZW1haW4gaW4gdGhpcyBwcm9wb3NhbC4NCg0KMy4xIEluZnJhc3RydWN0dXJlDQoN ClRoZSBmdW5kYW1lbnRhbCBwcmluY2lwbGUgaW4gdGhlIE5UUCBlbmdpbmVlcmluZyBkZXNp Z24gaXMgdGhhdCBubyBleHBsaWNpdCBpbmZyYXN0cnVjdHVyZSBvdGhlciB0aGFuIHRoZSBi YXNlIG5ldHdvcmsgaXMgYXNzdW1lZC4gVGhpcyBtZWFucyB0aGF0IG5laXRoZXIgRE5TIG5v ciBQS0kgY2VydGlmaWNhdGUgbWFuYWdlbWVudCBpbmZyYXN0cnVjdHVyZSBpcyBhdmFpbGFi bGUuIEluIHBhcnRpY3VsYXIsIHByaXZhdGUvcHVibGljIGtleXMgYW5kIGNlcnRpZmljYXRl cyBtdXN0IGJlIGdlbmVyYXRlZCBieSB0aGUgaG9zdCB0aGF0IHVzZXMgdGhlbS4gU2luY2Ug Y2VydGlmaWNhdGVzIGNhbm5vdCBiZSBhdXRoZW50aWNhdGVkIGJ5IG91dHNpZGUgbWVhbnMs IHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgb2YgYSBtaWRkbGVtYW4gYXR0YWNrIHdoZXJlIHRo ZSBhdHRhY2tlciBpbmplY3RzIGl0cyBjZXJ0aWZpY2F0ZSBvbiB0aGUgdHJhaWwgbGVhZGlu ZyB0byB0aGUgY2VydGlmaWNhdGUgYXV0aG9yaXR5Lg0KDQpJbiB0aGUgb3JpZ2luYWwgQXV0 b2tleSBkZXNpZ24gdGhlcmUgd2VyZSBvcHRpb25hbCBtZWFucyB0byB2ZXJpZnkgdGhlIGNl cnRpZmljYXRlIHRyYWlsIHVzaW5nIHRoZSBpZGVudGl0eSBleGNoYW5nZS4gVGhpcyBleGNo YW5nZSBpcyBubyBsb25nZXIgbmVlZGVkLCBzaW5jZSBrZXkgemVybywgZGVzY3JpYmVkIGJl bG93IGluIHRoZSAiTGF5ZXJlZCBNb2RlbCIgc2VjdGlvbiwgcGVyZm9ybXMgYSBzaW1pbGFy IGZ1bmN0aW9uLg0KDQo0LiBEaXZlcnNpdHkNCg0KSW4gdGhlIGN1cnJlbnQgTlRQIGFyY2hp dGVjdHVyZSwgdGhlIHRpbWUgYW5kIHNlY3VyaXR5IG9wZXJhdGlvbnMgcHJvY2VlZCBpbmRl cGVuZGVudGx5IGFuZCBzaW11bHRhbmVvdXNseSBmb3IgYWxsIGFzc29jaWF0aW9ucywgYXMg ZGVzY3JpYmVkIGJlbG93LiBTZWN1cml0eSBmb3IgYWxsIGFzc29jaWF0aW9ucyBpcyBtYW5h Z2VkIHNlcGFyYXRlbHkuIEFuIGFzc29jaWF0aW9uIGhhcyB2YWxpZCB0aW1lIHdoZW4gdGhl IGRpc3BlcnNpb24gaGFzIGZhbGxlbiBiZWxvdyB0aGUgdGhyZXNob2xkLiBUaGUgc2VjdXJp dHkgaXMgdmFsaWQgd2hlbiB0aGUgZmlyc3Qgc2lnbmF0dXJlIGlzIHZlcmlmaWVkLiBBbiBh c3NvY2lhdGlvbiBpcyB2YWxpZCB3aGVuIGJvdGggdGhlIHRpbWUgYW5kIHNlY3VyaXR5IGFy ZSB2YWxpZC4NCg0KVGhlIGFzc29jaWF0aW9ucyBhcmUgc2VsZWN0ZWQgYnkgdGhlIGNsb2Nr IGZpbHRlciwgQnl6YW50aW5lIGFncmVlbWVudCwgaW50ZXJzZWN0aW9uIGFuZCBjbHVzdGVy aW5nIGFsZ29yaXRobXMuIEl0IGRvZXMgbm90IHNlZW0gZmVhc2libGUgdG8gImxvb3NlbHkg c3luY2hyb25pemUiIHRoZSBzeXN0ZW0gY2xvY2sgd2l0aCB0aGlzIGRlc2lnbiwgc2luY2Ug b25seSBhZnRlciB0aGVzZSBhbGdvcml0aG1zIGhhdmUgY29tcGxldGVkIGlzIHRoZSBzeXN0 ZW0gY2xvY2sgZWxpZ2libGUgdG8gYmUgc3luY2hyb25pemVkLg0KDQo1LiBUd28tV2F5IElz c3Vlcw0KDQpJbiBicm9hZGNhc3QgbW9kZSwgYSB0d28td2F5IHBhdGggYmV0d2VlbiB0aGUg YnJvYWRjYXN0IHNlcnZlciBhbmQgY2xpZW50IGlzIG5lY2Vzc2FyeSB0byBjb21wdXRlIHRo ZSByb3VuZC10cmlwIGRlbGF5LiBIb3dldmVyLCBpbiBzb21lIHN1cHBvcnRlZCBjb25maWd1 cmF0aW9ucyBhIHJldHVybiBwYXRoIGlzIG5vdCBhdmFpbGFibGUgc28gdGhlIHJvdW5kLXRy aXAgZGVsYXkgY2Fubm90IGJlIGNvbXB1dGVkIGFuZCBtdXN0IGJlIGVzdGltYXRlZC4gSXQg aXMgbm90IHRoZW4gcG9zc2libGUgdG8gcmV0cmlldmUgYW55IHNlcnZlciBkYXRhIG90aGVy IHRoYW4gdGhlIGJyb2FkY2FzdCBwYWNrZXQgaXRzZWxmLiBUaGUgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIHN1cHBvcnRzIGJvdGggYSBvbmUtd2F5IGFuZCB0d28td2F5IGRlc2lnbiB1 c2luZyBhbiBvcHRpb25hbCBjbGllbnQgc2VydmVyIGV4Y2hhbmdlIHRvIGNvbXB1dGUgdGhl IHJvdW5kLXRyaXAgZGVsYXkgZm9sbG93ZWQgYnkgb25lLXdheSBicm9hZGNhc3QgcGFja2V0 cy4NCg0KNi4gQWNjZXNzIENvbnRyb2wNCg0KVGhlIGN1cnJlbnQgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uIGluY2x1ZGVzIGFjY2VzcyBjb250cm9scyBpbiB0aGUgZm9ybSBvZiBiaXQg cGVybWlzc2lvbnMgYW5kIHJhdGUgbWFuYWdlbWVudCBwYXJhbWV0ZXJzLiBUaGVyZSBpcyBu byBuZWVkIGZvciBhZGRpdGlvbmFsIGFjY2VzcyBjb250cm9sIGZ1bmN0aW9uIGluIHRoZSBj cnlwdG9ncmFwaGljIGFsZ29yaXRobXMuIE90aGVyIHB1YmxpYyBrZXkgc2NoZW1lcyBtYXkg d2lzaCB0byB1c2UgYW4gYWNjZXNzIGV4Y2hhbmdlIHByb3ZpZGluZyBhIHNlc3Npb24ga2V5 IGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIHByb3RvY29sLCBhbHRob3VnaCB0aGUgb24td2ly ZSBwcm90b2NvbCBsYXllciBwcm92aWRlcyBhIHNpbWlsYXIgZnVuY3Rpb24uDQoNClJhdGUg bWFuYWdlbWVudCBpc3N1ZXMgYXJlIGEgY3JpdGljYWwgY29uc2lkZXJhdGlvbiBpbiB0aGUg c2VjdXJpdHkgcHJvdG9jb2wgZGVzaWduLiBGb3IgZXhhbXBsZSwgYSBidXN5IE5JU1Qgc2Vy dmVyIHByb2Nlc3NlcyBvdmVyIDMwMDAgTlRQIHBhY2tldHMgcGVyIHNlY29uZC4gQXMgbGVh cm5lZCBmcm9tIGV4cGVyaWVuY2UsIHRoZSBwcmltYXJ5IGNvbXBvbmVudCBvZiBDUFUgY3lj bGVzIGlzIHRoZSBwZXItcGFja2V0IG92ZXJoZWFkLCBzb21lIHRob3VzYW5kcyBvZiBpbnN0 cnVjdGlvbnMgcGVyIHBhY2tldC4gVGhpcyBvdmVyaGVhZCBpcyBzdWJzdGFudGlhbGx5IGlu ZGVwZW5kZW50IG9mIHBhY2tldCBsZW5ndGggb3IgbnVtYmVyIG9mIGV4dGVuc2lvbiBmaWVs ZHMuDQoNClRoZSBjdXJyZW50IHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiBsaW1pdHMgdGhl IG1pbmltdW0gcGFja2V0IGhlYWR3YXkgYW5kIG1pbmltdW0gYXZlcmFnZSBoZWFkd2F5IHRv IGNvbmZpZ3VyZWQgdmFsdWVzLiBDbGllbnRzIHRoYXQgdmlvbGF0ZSB0aGVzZSBsaW1pdHMg YXJlIGRlbmllZCBzZXJ2aWNlLiBGb3IgZXhhbXBsZSwgYXQgTklTVCwgYSBzaWduaWZpY2Fu dCBtaW5vcml0eSBvZiBjbGllbnRzIHJvdXRpbmVseSB2aW9sYXRlIHRoZSBtaW5pbXVtIGhl YWR3YXkgcmVxdWlyZW1lbnQgb2YgdHdvIHNlY29uZHMgYW5kIHNvIGFyZSBkaXNjYXJkZWQu IEFuIG9wdGlvbmFsIGtpc3MgbycgZGVhdGggKEtvRCkgaXMgYXZhaWxhYmxlIHRvIHF1ZW5j aCBjb21wbGlhbnQgY2xpZW50cy4NCg0KVGhlIHJhdGUgbWFuYWdlbWVudCBwYXJhbWV0ZXJz IGFwcGx5IGJvdGggdG8gdGhlIE5UUCBwYWNrZXQgZmxvd3MsIGFzIHdlbGwgYXMgdGhlIHNl Y3VyaXR5IGhhbmRzaGFrZSBmdW5jdGlvbi4gQXMgdGhpcyBmdW5jdGlvbiBvZnRlbiBpbnZv bHZlcyBtdWx0aXBsZSBwYWNrZXRzLCB0aGlzIG1heSByZXN1bHQgaW4gZXhjZXNzaXZlIGFj cXVpc2l0aW9uIHRpbWVzLiBUaGUgbWVhbnMgZGVzY3JpYmVkIGJlbG93IHByb3ZpZGUgYSB3 YXkgdG8gbWluaW1pemUgdGhlIG51bWJlciBvZiBwYWNrZXRzIHRvIGNvbXBsZXRlIHRoZSBo YW5kc2hha2UgZnVuY3Rpb24uDQoNCjcuIE5UUCBTZWN1cmUgTmV0d29yayBFbmdpbmVlcmlu ZyBQcmluY2lwbGVzDQoNCkFuIE5UUCBzZWN1cmUgbmV0d29yayBjb25zaXN0cyBvZiBhbiBh Y3ljbGljLCBkaXJlY3RlZCBncmFwaCBvcmdhbml6ZWQgYXMgYSB0cmVlIHdpdGggbm9kZXMg ZGVzY2VuZGluZyBmcm9tIHRoZSByb290IG5vZGUuIFRoZSBub2RlcyBjb3JyZXNwb25kIHRv IHRoZSBOVFAgaG9zdHMgYW5kIHRoZSBlZGdlcyBjb3JyZXNwb25kIHRvIHRoZSBuZXR3b3Jr IHBhdGhzIGJldHdlZW4gdGhlbS4gVGhlIG5ldHdvcmsgcGF0aHMgaW5jbHVkZSBvbmUgb3Ig bW9yZSBwaHlzaWNhbCBsaW5rcywgaW50ZXJjb25uZWN0ZWQgYnkgcm91dGVycyBhbmQgZmly ZXdhbGxzLiBOb3RlIHRoYXQgdGhlIG5ldHdvcmsgdG9wb2xvZ3kgY2FuIGNoYW5nZSBmcm9t IHRpbWUgdG8gdGltZSBkdWUgdG8gaG9zdCBvciBuZXR3b3JrIHBhdGggZmFpbHVyZXMuDQoN CkEgbnVtYmVyIG9mIHRyZWVzIGNhbiBiZSBhcnJhbmdlZCBhcyBhIGZvcmVzdCwgd2hlcmUg YW4gZWRnZSBvZiBvbmUgdHJlZSBjYW4gdGVybWluYXRlIG9uIGEgaG9zdCBvZiBhIGRpZmZl cmVudCB0cmVlLiAgVGhlIHRyZWVzICBvZiB0aGUgZm9yZXN0IHVzdWFsbHkgaGF2ZSBkaWZm ZXJlbnQgcm9vdCBzZXJ2ZXJzIGFzIHRydXN0IGFuY2hvcnMuDQoNCkZvciB0aGUgcHVycG9z ZXMgb2YgbmV0d29yayBzZWN1cml0eSwgZWFjaCBob3N0IGNhbiBjb21tdW5pY2F0ZSBkaXJl Y3RseSBvbmx5IHdpdGggaXRzIGltbWVkaWF0ZSB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBo b3N0KHMpLiBBIGhvc3QgY2FuIG9wZXJhdGUgYXMgYSBjbGllbnQgYW5kL29yIHNlcnZlci4g RWFjaCBob3N0IGluY2x1ZGVzIGEgc2V0IG9mIHB1YmxpYy9wcml2YXRlIGtleXMgYW5kIG9u ZSBvciBtb3JlIGNlcnRpZmljYXRlcy4gRWFjaCBzaWduZWQgY2VydGlmaWNhdGUgY29uZmly bXMgYXV0aGVudGljaXR5IG9mIGl0cyBwdWJsaWMga2V5LiBQdWJsaWMvcHJpdmF0ZSBrZXlz IGFuZCBob3N0IGNlcnRpZmljYXRlcyBhcmUgZ2VuZXJhdGVkIGluZGl2aWR1YWxseSBieSBl YWNoIGhvc3QuDQoNClRoZSBnb2FsIG9mIHRoZSBzZWN1cml0eSBzY2hlbWUgaXMgdG8gYXV0 aGVudGljYXRlIGVhY2ggc2VydmVyIHRvIHRoZSBuZXh0IGRvd25zdHJlYW0gY2xpZW50IHVz aW5nIG9uZSBvciBtb3JlIGNlcnRpZmljYXRlcy4gVGhlIHJlY3Vyc2l2ZSBzY2hlbWUgZXZv bHZlcyBhcyBmb2xsb3dzOg0KDQpJbiB0aGUgYmFzaXMgc3RlcCwgdGhlIHJvb3Qgc2VydmVy IGhvc3QgaXMgZGVzaWduYXRlZCBhdXRoZW50aWMgYnkgc29tZSBtZWFucyBleHRlcm5hbCB0 byB0aGUgbmV0d29yay4gRm9yIGluc3RhbmNlLCBhbiBleHRlcm5hbCBjZXJ0aWZpY2F0ZSBh dXRob3JpdHkgY2FuIHNpZ24gdGhlIHJvb3QgY2VydGlmaWNhdGUuIEluIHRoZSBpbmR1Y3Rp dmUgc3RlcCwgZWFjaCBjbGllbnQgaG9zdCBpbiB0aGUgbmV0d29yayBzZXBhcmF0ZWx5IHJl cXVlc3RzIGl0cyBpbW1lZGlhdGUgYXNjZW5kaW5nIHNlcnZlciBob3N0IHRvIHNpZ24gaXRz IGNsaWVudCBob3N0IGNlcnRpZmljYXRlLg0KDQpJZiB0aGUgc2VydmVyIGhvc3QgaXMgZGVz aWduYXRlZCBhdXRoZW50aWMsIHRoZSBjbGllbnQgaG9zdCBpcyBhbHNvIGRlc2lnbmF0ZWQg YXV0aGVudGljLiBJZiB0aGUgc2VydmVyIGhvc3QgaXMgbm90IGF1dGhlbnRpYywgdGhlIHJl cXVlc3QgaXMgaWdub3JlZCBhbmQgdGhlIGNsaWVudCByZXF1ZXN0IGlzIHJlcGVhdGVkIGFm dGVyIHRpbWVvdXQuDQoNCkluIHRoaXMgZmFzaGlvbiwgZXZlbnR1YWxseSBhbGwgY2xpZW50 IGNlcnRpZmljYXRlcyBhcmUgc2lnbmVkIGFuZCBkZXNpZ25hdGVkIGF1dGhlbnRpYy4gVGh1 cywgYXV0aGVudGljaXR5IGZsb3dzIGluIHN0ZXBzIGZyb20gdGhlIGNlcnRpZmljYXRlIGF1 dGhvcml0eSB0byBlYWNoIGRvd25zdHJlYW0gaG9zdCBpbiB0aGUgbmV0d29yay4NCg0KT25j ZSBnZW5lcmF0ZWQsIGNlcnRpZmljYXRlcyBoYXZlIGEgc3BlY2lmaWMgYXNzaWduZWQgbGlm ZXRpbWUuIFNvbWUgdGltZSBiZWZvcmUgZXhwaXJhdGlvbiBvZiB0aGUgbGlmZXRpbWUsIGEg bmV3IGNlcnRpZmljYXRlIG11c3QgYmUgZ2VuZXJhdGVkIHdpdGggYSBuZXcgbGlmZXRpbWUu IFRoaXMgZG9lcyBub3QgYWZmZWN0IHRoZSBhdXRoZW50aWNpdHkgb3Igb3RoZXIgcGFyYW1l dGVycyBvZiB0aGUgY3VycmVudCBjZXJ0aWZpY2F0ZS4gT24gdGhlIG90aGVyIGhhbmQsIGEg bmV3IHNldCBvZiBwdWJsaWMvcHJpdmF0ZSBrZXlzIHJlcXVpcmUgdGhlIGNlcnRpZmljYXRl IHRvIGJlIHJlZ2VuZXJhdGVkIGFuZCBpdHMgcHVibGljIGtleSB0byBiZSByZS1zaWduZWQg YnkgdGhlIHNlcnZlci4gVGhlIHNjaGVtZSB0byBkbyB0aGlzIGlzIHN0cmFpZ2h0Zm9yd2Fy ZCwgYnV0IGludHJpY2F0ZSwgYXMgZGVzY3JpYmVkIGJlbG93Lg0KDQpBIGhvc3QgaXMgY29u c2lkZXJlZCBwcm92aXNpb25hbGx5IGF1dGhlbnRpYyB3aGVuIHRoZSBzaGFyZWQgaGFzaCBr ZXkgc2lnbmF0dXJlcyBoYXZlIGJlZW4gdmVyaWZpZWQuIFRoZSBob3N0IGlzIGNvbnNpZGVy ZWQgZnVsbHkgYXV0aGVudGljIHdoZW4gaXRzIGNlcnRpZmljYXRlIGhhcyBiZWVuIHNpZ25l ZCBieSB0aGUgbmV4dCBhc2NlbmRpbmcgaG9zdCBvbiB0aGUgdHJhaWwgdG8gdGhlIGNlcnRp ZmljYXRlIGF1dGhvcml0eS4NCg0KVGhlIGNlcnRpZmljYXRlIHRyYWlsIGlzIHRodXMgY29u c3RydWN0ZWQgc3RlcCBieSBzdGVwIGFzIGVhY2ggc2lnbmF0dXJlIGlzIGNvbnN0cnVjdGVk IG9yIHZlcmlmaWVkLiBFYWNoIHN0ZXAgaW52b2x2ZXMgYSBzaWduIGV4Y2hhbmdlLCBhcyBk ZXNjcmliZWQgbGF0ZXIgaW4gdGhlIOKAnFB1YmxpYyBLZXkgTGF5ZXLigJ0gc2VjdGlvbi4g QXNzdW1pbmcgdGhlIGhvc3QgdGltZSB0byBiZSBjb3JyZWN0LCB0aGUgdHJhaWwgbmVlZHMg dG8gYmUgdmVyaWZpZWQgb25seSBvbmNlLg0KDQpOb3RlIHRoYXQgdGhpcyBtb2RlbCBkb2Vz IG5vdCBjb25zdHJ1Y3QgdGhlIGNlcnRpZmljYXRlIHRyYWlsIGluIGVhY2ggY2xpZW50IGhv c3QuIEluIGZvcm1lciBkZXNpZ25zLCB0aGlzIHdhcyBhY2hpZXZlZCB1c2luZyBhIHBlcnNp c3RlbnQgY2FjaGUgd2hpY2ggaGFkIHRvIGJlIHVwZGF0ZWQgb24gYSByZWd1bGFyIGJhc2lz LiBIb3dldmVyLCBib3RoIHRoZSBjdXJyZW50IGFuZCBwcm9wb3NlZCBtb2RlbHMgYXJlIHZ1 bG5lcmFibGUgdG8gbWlkZGxlbWFuIGF0dGFjay4gVGhlIG9yaWdpbmFsIHNvbHV0aW9uIGZv ciB0aGlzIHByb2JsZW0gd2FzIHRoZSBTY2hub3JyIChJRkYpIGlkZW50aXR5IHNjaGVtZSBk ZXNjcmliZWQgaW4gUkZDNTkwNi4gVGhlIHNjaGVtZSBwcm9wb3NlZCBpbiB0aGlzIGRvY3Vt ZW50IHJlcGxhY2VzIHRoZSBJRkYgc2NoZW1lIHdoaWxlIHBlcmZvcm1pbmcgdGhlIHNhbWUg ZnVuY3Rpb24uDQoNCjguIExheWVyZWQgTW9kZWwNCg0KVGhlIHNlY3VyaXR5IG1vZGVsIGlu IHRoZSBnZW5lcmljIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiBSRkM1OTA1IGNhbiBiZSBz dW1tYXJpemVkIGFzIGEgZm91ci1sYXllciBtb2RlbCwgZGVzY3JpYmVkIGJlbG93LiBOb3Rl IHRoYXQgdGhlIHByb3RvY29sIG1lc3NhZ2VzIGhpdGNoaGlrZSBvbiB0aGUgTlRQIHBhY2tl dCBoZWFkZXJzIGFzIHRyYW5zbWl0dGVkLiBOb3RlIGFsc28gdGhhdCB0aGUgcGFja2V0IHBv bGwgaW50ZXJ2YWwgZHVyaW5nIHRoZSBzZWN1cml0eSBkYW5jZSBjYW4gYmUgcmVkdWNlZCBj b25zaXN0ZW50IHdpdGggdGhlIHJhdGUgbGltaXRzLg0KDQo4LjEgRm9ybWF0IExheWVyDQoN CldoZW4gYW4gTlRQIHBhY2tldCBhcnJpdmVzLCB0aGUgZmlyc3QgbGF5ZXIgdmVyaWZpZXMg dGhlIHBhY2tldCBmb3JtYXQuIEluIHBhcnRpY3VsYXIsIHRoZSBtYXhpbXVtIHBhY2tldCBz aXplLCBwYWNrZXQgaGVhZGVyIGFuZCBleHRlbnNpb24gZmllbGQgc2l6ZXMsIGlmIHByZXNl bnQsIGFyZSBjaGVja2VkLiBFeHRlbnNpb24gZmllbGRzIGFyZSBjaGVja2VkIGJ1dCBub3Qg cHJvY2Vzc2VkIGF0IHRoaXMgdGltZS4NCg0KVGhlIGZvcm1hdCBzY2FuIHJlc3VsdHMgaW4g YSBwb2ludGVyIGp1c3QgYmVmb3JlIHRoZSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUg KE1BQykuIFRoaXMgZGVzaWduYXRlcyB0aGUgdXBwZXIgbGltaXQgb2YgdGhlIGhhc2ggY29t cHV0YXRpb24uIEluIGNhc2Ugb2YgZm9ybWF0IGVycm9yLCB0aGUgcGFja2V0IGlzIGRpc2Nh cmRlZCB3aXRoIG5vIGZ1cnRoZXIgYWN0aW9uLg0KDQo4LjIgU3ltbWV0cmljIEtleSBMYXll cg0KDQpUaGUgc2Vjb25kIGxheWVyIHZlcmlmaWVzIHBhY2tldCBkYXRhIGNvbnRlbnQuIElu IHRoZSBOVFAgZ2VuZXJpYyBzZWN1cml0eSBtb2RlbCwgTlRQIHBhY2tldHMgYXJlIGNvbnNp ZGVyZWQgcHVibGljIHZhbHVlcyBzbyB0aGV5IGFyZSBub3QgZW5jcnlwdGVkLiBIb3dldmVy LCBpdCBpcyB2aXRhbCB0aGF0IHRoZSBwYWNrZXQgYmUgdW5kYW1hZ2VkIGluIHRyYW5zaXQg YW5kIHRoZSBwYWNrZXQgb3JkZXIgYmUgcHJlc2VydmVkLiBBbHRob3VnaCB0aGUgcHJvdG9j b2wgaXMgcXVpdGUgcmVzaXN0YW50IHRvIHBhY2tldCBsb3NzLCByZXRyYW5zbWlzc2lvbnMg aGF2ZSBubyB2YWx1ZSBhbmQgYXJlIGlnbm9yZWQuDQoNClBhY2tldCBkYXRhIGludGVncml0 eSBpcyBwcm90ZWN0ZWQgYnkgYSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgKE1BQyks IHdoaWNoIGlzIHVzZWQgZm9yIGFsbCBwYWNrZXRzLiBUaGUgTUFDIGlzIG9yZGluYXJpbHkg Y29uc3RydWN0ZWQgYW5kIHZlcmlmaWVkIHVzaW5nIGEgaGFzaCBrZXkgc2hhcmVkIGJ5IHRo ZSBjbGllbnQgYW5kIHNlcnZlci4gVGhlIGhhc2gga2V5IGlzIGFzc3VtZWQgcHJpdmF0ZSBh bmQgdW5wcmVkaWN0YWJsZSBmb3IgZWFjaCBhc3NvY2lhdGlvbi4NCg0KSWYgYSBzaGFyZWQg aGFzaCBrZXkgaXMgbm90IGF2YWlsYWJsZSwgc3VjaCBhcyBkdXJpbmcgdGhlIGFncmVlbWVu dCBwcm9jZXNzIGl0c2VsZiwgYW4gaW1wbGljaXQgaGFzaCBrZXkgemVybyBpcyBhc3N1bWVk LiBUaGUgdmFsdWUgb2YgaGFzaCBrZXkgemVybyBpcyBhIHJhbmRvbSBudW1iZXIga25vd24g b25seSB0byB2ZXJpZmllZCBhbmQgdHJ1c3RlZCBob3N0cyBpbiB0aGUgTlRQIG5ldHdvcmsu IFRoZSBkZXNpZ24gaW50ZW50IGlzIHRvIHZlcmlmeSB0aGlzIG51bWJlciBhcyB3ZWxsIGFz IGRldGVjdCBlcnJvcnMsIHJhdGhlciB0aGFuIHByb3RlY3QgYWdhaW5zdCBtaWRkbGVtYW4g YXR0YWNrLiBCeSBwcm90b2NvbCBydWxlLCBpZiBhIG1lc3NhZ2UgcmVxdWVzdCB1c2VzIGtl eSB6ZXJvLCB0aGUgbWVzc2FnZSByZXNwb25zZSBhbHNvIHVzZXMga2V5IHplcm8uIE5vdGUg dGhhdCBhbnkgYWdyZWVkLXVwb24gc3ltbWV0cmljIGtleSBpbiB0aGUgbnRwLmtleXMgZmls ZSBjb3VsZCBiZSB1c2VkIHRvIGZ1bGZpbGwgdGhlIHJvbGUgb2Yga2V5IHplcm8uDQoNCkJ5 IHNwZWNpZmljYXRpb24sIGEgc2VjdXJlIHNlcnZlciBjYW4gd29yayB3aXRoIG9yIHdpdGhv dXQgYSBNQUMuIFdpdGhvdXQgYSBNQUMgYSBwYWNrZXQgaXMgdW5jb25kaXRpb25hbGx5IGFj Y2VwdGVkOyB3aXRoIGEgTUFDIGEgcGFja2V0IGlzIGFjY2VwdGVkIG9ubHkgaWYgdmVyaWZp ZWQgYnkgc2VjdXJlIG1lYW5zLiBBIGNvbmZpZ3VyYXRpb24gYml0IGNhbiBiZSB1c2VkIHRv IGRpc2NhcmQgcGFja2V0cyB3aXRob3V0IGEgTUFDLg0KDQpJbiBjYXNlIG9mIGhhc2ggZmFp bHVyZSwgdGhlIHBhY2tldCBpcyBkaXNjYXJkZWQgYW5kIGEgY3J5cHRvLU5BSyBtZXNzYWdl IHJldHVybmVkIHRvIHRoZSBzZW5kZXIuIFRoZSBjcnlwdG8tTkFLIGNvbnNpc3RzIG9mIGEg NC1vY3RldCBleHRlbnNpb24gZmllbGQgY29udGFpbmluZyBhbiBvcHRpb25hbCBlcnJvciBj b2RlLiBBIGNyeXB0by1OQUsgcGFja2V0IGlzIGFsd2F5cyBzZW50IHdpdGgga2V5IHplcm8u IFRoZSBjcnlwdG8tTkFLIG9yZGluYXJpbHkgcmVzdWx0cyBpbiBhIHJlbmVnb3RpYXRpb24g b2YgdGhlIHNoYXJlZCBoYXNoIGtleSwgYXMgZGVzY3JpYmVkIGJlbG93LiBJbiBjYXNlIG9m IGJyb2FkY2FzdCBtb2RlLCBhIGRpZmZlcmVudCBzdHJhdGVneSBpcyB1c2VkLCBhcyBkZXNj cmliZWQgYmVsb3cuDQoNCklmIHRoZSBoYXNoIHNpemUgaXMgdG9vIGxhcmdlLCBpdCBjYW4g Y29tcHJvbWlzZSB0aW1pbmcgYWNjdXJhY3k7IGlmIHRvbyBzbWFsbCwgaXQgY2FuIGNvbXBy b21pc2Ugc2VjdXJpdHkuIEEgbmF0dXJhbCBjaG9pY2UgaXMgMTYwIGJpdHMgb3IgMjAgb2N0 ZXRzLCBhcyBpbiB0aGUgY3VycmVudCByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24uIEFuIGF0 dHJhY3RpdmUgc3RyYXRlZ3kgaXMgdGhlIHVzZSBvZiBlbGxpcHRpYy1jdXJ2ZSB2ZXJzaW9u cyBvZiB0aGUgYWdyZWVtZW50IGFuZCBzaWduYXR1cmUgYWxnb3JpdGhtcy4gVXNpbmcgdGhl c2UgYWxnb3JpdGhtcywgYSAxNjAgYml0IGhhc2ggc2l6ZSBpcyBlcXVpdmFsZW50IHRvIGEg MTAyNCBiaXQgaGFzaCBzaXplIHVzaW5nIHRoZSB0cmFkaXRpb25hbCBhbGdvcml0aG1zLg0K DQpJbiB0aGUgaGlzdG9yaWMgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uLCBhIE1BQyBpcyBp bmRpY2F0ZWQgYXMgdGhlIGxhc3QgYmxvY2sgYWZ0ZXIgYWxsIGV4dGVuc2lvbiBmaWVsZHMg aW4gdGhlIHBhY2tldC4gVGhlIGJsb2NrIGxlbmd0aCBpcyB0cmFkaXRpb25hbGx5IG5vdCBn cmVhdGVyIHRoYW4gMjQgb2N0ZXRzIC0gNCBvY3RldHMgZm9yIHRoZSBrZXkgSUQgcGx1cyAy MCBvY3RldHMgZm9yIHRoZSBoYXNoLiBGb3Igc3ltbWV0cmljIGtleXMsIHRoZSBoaWdoLW9y ZGVyIHR3byBvY3RldHMgb2YgdGhlIGtleSBJRCBhcmUgemVybyBhbmQgdGhlIGxvdy1vcmRl ciB0d28gb2N0ZXRzIGFyZSB0aGUgZW50cnkgbnVtYmVyIGluIHRoZSBrZXlzIGZpbGUuIFRo aXMgZm9ybWF0IGlzIG5lY2Vzc2FyeSBvbmx5IGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 IHdpdGggdGhlIHN5bW1ldHJpYyBrZXkgZmlsZS4NCg0KSXQgaXMgbm90IGdlbmVyYWxseSB1 c2VmdWwgdG8gcHJvdmlkZSBsYXJnZXIgaGFzaCBzaXplcy4gRm9yIGV4YW1wbGUsIHRoZSBT SEExNjAgaGFzaCBhbGdvcml0aG0gaXMgYSAyMC1vY3RldCB0cnVuY2F0ZWQgdmVyc2lvbiBv ZiBTSEEyNTYuIE90aGVyIGhhc2ggYWxnb3JpdGhtcyBjYW4gYmUgdHJ1bmNhdGVkIGFzIHdl bGwuDQoNCkluIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24sIHRoZSBoYXNoIGFsZ29y aXRobSBjYW4gYmUgc3BlY2lmaWVkIGZvciBlYWNoIGtleSBudW1iZXIgaW4gdGhlIGtleXMg ZmlsZS4gSW4gcHJpbmNpcGxlLCBrZXkgemVybyBjYW4gYmUgYXNzaWduZWQgaW4gdGhlIGtl eXMgZmlsZSBhcyB3ZWxsLCBwcm92aWRpbmcgYW4gaW5kZXBlbmRlbnQgY2hvaWNlIG9mIGhh c2ggYWxnb3JpdGhtLg0KDQpUaGUgT3BlblNTTCBsaWJyYXJ5IGluY2x1ZGVzIGp1c3QgYWJv dXQgZXZlcnkgaGFzaCBhbGdvcml0aG0gbGlrZWx5IHRvIGJlIGltYWdpbmVkLiBXaGlsZSBo aXN0b3JpY2FsbHkgYW1iaWd1b3VzLCB0aGUgSW50ZXJuYXRpb25hbCBUcmFkZSBpbiBBcm1z IFJlZ3VsYXRpb25zIChJVEFSKSBwcm9oaWJpdHMgZXhwb3J0IG9mIHRoZSBPcGVuU1NMIGxp YnJhcnksIHNvIG9ubHkgdGhlIE1ENSBoYXNoIGFsZ29yaXRobSBpcyBpbmNsdWRlZCBpbiB0 aGUgcmVmZXJlbmNlIGRpc3RyaWJ1dGlvbi4gQWx0ZXJuYXRpdmVseSwgdGhlIE9wZW5TU0wg bGlicmFyeSBjYW4gYmUgaW1wb3J0ZWQgZnJvbSBmb3JlaWduIG9yIGRvbWVzdGljIHNvdXJj ZXMsIGFsdGhvdWdoIHRoZSByZXN1bHRpbmcgcHJvZHVjdCBtYXkgbm90IGJlIGV4cG9ydGVk IGZyb20gdGhlIFVTLg0KDQpBbHRlcm5hdGVseSBvciBpbiBhZGRpdGlvbiwgYSBoYXNoIG9m IGFyYml0cmFyeSBzaXplIGNhbiBiZSBpbXBsZW1lbnRlZCB1c2luZyBhbiBleHRlbnNpb24g ZmllbGQuIEluIHRoaXMgY2FzZSwgdGhlIGxlbmd0aCBvY3RldHMgaW4gdGhlIGtleSBJRCB3 aWxsIGJlIG5vbnplcm8gYW5kIHRoZSBtb2RpZmllciBvY3RldCB1c2VkIGFzIHRoZSBrZXkg bnVtYmVyLiBUaGUgaGFzaCBpcyBjb21wdXRlZCBmcm9tIHRoZSBiZWdpbm5pbmcgb2YgdGhl IHBhY2tldCB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBNQUMuIE9yZGluYXJpbHksIHRoZSBN QUMgaXMgdGhlIGxhc3QgZXh0ZW5zaW9uIGZpZWxkIGluIHRoZSBwYWNrZXQsIGJ1dCBhZGRp dGlvbmFsIGV4dGVuc2lvbiBmaWVsZHMgYmV5b25kIHRoZSBNQUMgYXJlIHBvc3NpYmxlLCB0 aG91Z2ggbm90IGluY2x1ZGVkIGluIHRoZSBoYXNoIGNvbXB1dGF0aW9uLg0KDQo4LjMgT24t V2lyZSBQcm90b2NvbCBMYXllcg0KDQpUaGUgdGhpcmQgbGF5ZXIgdmVyaWZpZXMgcHJvdG9j b2wgb3BlcmF0aW9ucyBjb25zaXN0ZW50IHdpdGggdGhlIG9uLXdpcmUgcHJvdG9jb2wuIFRo ZSBwcm90b2NvbCBkaXNjYXJkcyBib2d1cyBhbmQgZHVwbGljYXRlIHBhY2tldHMgYXMgd2Vs bCBhcyBtaW5pbWl6ZXMgZGlzcnVwdGlvbnMgZHVlIHRvIHByb3RvY29sIHJlc3RhcnRzIGFu ZCBkcm9wcGVkIHBhY2tldHMuIFRoZSBvcGVyYXRpb25zIGFyZSBjb250cm9sbGVkIGJ5IHR3 byB0aW1lc3RhbXBzOiB0aGUgdHJhbnNtaXQgdGltZXN0YW1wIHNhdmVkIGluIHRoZSBjbGll bnQgc3RhdGUgdmFyaWFibGVzIGFuZCB0aGUgb3JpZ2luIHRpbWVzdGFtcCBpbiB0aGUgc2Vy dmVyIHBhY2tldCBoZWFkZXIuIFRoZSBjb21wYXJpc29uIG9mIHRoZXNlIHR3byB0aW1lc3Rh bXBzIGlzIGNhbGxlZCB0aGUgbG9vcGJhY2sgdGVzdC4gVGhlIHRyYW5zbWl0IHRpbWVzdGFt cCBmdW5jdGlvbnMgYXMgYSBub25jZSB0byB2ZXJpZnkgdGhhdCB0aGUgcmVzcG9uc2UgY29y cmVzcG9uZHMgdG8gdGhlIG9yaWdpbmFsIHJlcXVlc3QuIFRoZSB0cmFuc21pdCB0aW1lc3Rh bXAgYWxzbyBzZXJ2ZXMgdG8gZGlzY2FyZCByZXBsYXlzIG9mIHRoZSBtb3N0IHJlY2VudCBw YWNrZXQuDQoNClVwb24gZmFpbHVyZSBvZiBlaXRoZXIgdGVzdCwgdGhlIHBhY2tldCBpcyBk aXNjYXJkZWQgd2l0aCBubyBmdXJ0aGVyIGFjdGlvbi4gSW4gb3JkZXIgdG8gcmVkdWNlIHJv dW5kb2ZmIGVycm9ycyBhbmQgaW1wcm92ZSBzZWN1cml0eSwgdGhlIGxvdyBvcmRlciBub25z aWduaWZpY2FudCBiaXRzIG9mIHRoZSB0aW1lc3RhbXAgYXJlIHJlcGxhY2VkIGJ5IGEgcmFu ZG9tIGJpdCBzdHJpbmcuDQoNClRoZSB0cmFuc21pdCB0aW1lc3RhbXAgbWlnaHQgbm90IGJl IGNvbnNpZGVyZWQgc3VmZmljaWVudGx5IHJhbmRvbSBhcyBhIG5vbmNlLiBIb3dldmVyLCB0 aGUgdGltZXN0YW1wcyBhcmUgYWx3YXlzIGluY3JlYXNpbmcsIGV2ZW4gaWYgYnkgYSBzbWFs bCBhbW91bnQsIGFuZCB0aGUgdGltZXN0YW1wcyBhcmUgbmV2ZXIgcHJlZGljdGFibGUuIFRo ZXJlZm9yZSwgaW4gdGhpcyBwcm9wb3NhbCwgdHJhbnNtaXQgdGltZXN0YW1wcyBhcmUgY29u c2lkZXJlZCB2YWxpZCBub25jZXMuDQpBbiBpbXBvcnRhbnQgZnVuY3Rpb24gb2YgdGhlIG9u LXdpcmUgbGF5ZXIgaXMgY29sbGVjdGlvbiBvZiBwYWNrZXQgdGltZXN0YW1wcywgYm90aCBp bnB1dCBhbmQgb3V0cHV0LiBUaGVyZSBhcmUgdGhyZWUga2luZHMgb2YgdGltZXN0YW1wcywg aW4gb3JkZXIgb2YgaW5jcmVhc2luZyBhY2N1cmFjeTogc29mdHN0YW1wcywgZHJpdmVzdGFt cHMgYW5kIGhhcmRzdGFtcHMuIFRoZXNlIGFyZSBkZXRlcm1pbmVkIGJ5IHJlYWRpbmcgdGhl IHN5c3RlbSBjbG9jayBhdCBzcGVjaWZpZWQgcHJvdG9jb2wgZXZlbnRzLiBTb2Z0c3RhbXBz IGFyZSBkZXRlcm1pbmVkIHdoZW4gYSBwYWNrZXQgaXMgcmVtb3ZlZCBmcm9tIHRoZSBpbnB1 dCBxdWV1ZSBhbmQgd2hlbiBhIHBhY2tldCBpcyBhZGRlZCB0byB0aGUgb3V0cHV0IHF1ZXVl LiBEcml2ZXN0YW1wcyBhcmUgZGV0ZXJtaW5lZCBhdCB0aGUgdGltZSBvZiB0aGUgZGV2aWNl IGludGVycnVwdCBhdCB0aGUgZW5kIG9mIHRoZSBwYWNrZXQuIFRoZXkgYXJlIHVzZWQgYnkg dGhlIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiBhbmQgaW4gcGFydGljdWxhciB0aGUgaW50 ZXJsZWF2ZSBwcm90b2NvbC4gSGFyZHN0YW1wcyBhcmUgZGV0ZXJtaW5lZCBhdCBzcGVjaWZp YyBldmVudHMgZGV0ZXJtaW5lZCBieSBzcGVjaWFsaXplZCBpbnRlcmZhY2UgaGFyZHdhcmUu IFRoZXkgYXJlIG5vdCB1c2VkIGluIHRoZSBjdXJyZW50IHJlZmVyZW5jZSBpbXBsZW1lbnRh dGlvbi4NCg0KRHJpdmVzdGFtcHMgYXJlIHRoZSBtYWluIGRldGVybWluYW50IG9mIHRpbWVr ZWVwaW5nIGFjY3VyYWN5LiBUaGV5IG11c3QgYmUgY29sbGVjdGVkIGF0IHRoZSBkZXZpY2Ug bGF5ZXIgYW5kIHBhc3NlZCB1cHdhcmRzIGluIHRoZSBpbnB1dCBwYWNrZXQgYnVmZmVyIG9y IGF0IHRoZSBlbmQgb2YgdGhlIG91dHB1dCBvcGVyYXRpb24uIFRoaXMgY2FuIGNvbXBsaWNh dGUgdGhlIHNlY3VyaXR5IHByb3RvY29sLCBlc3BlY2lhbGx5IGlmIHVzaW5nIGEgcHJlcGFj a2FnZWQgc2VjdXJpdHkgaW1wbGVtZW50YXRpb24uDQoNCjguNCBQdWJsaWMgS2V5IExheWVy DQoNClRoZSBmb3VydGggbGF5ZXIgY29uc3RydWN0cyBhbmQgYXV0aGVudGljYXRlcyB0aGUg c2hhcmVkIGhhc2gga2V5IGFuZCBjZXJ0aWZpY2F0ZSB0cmFpbCB0byB0aGUgY2VydGlmaWNh dGUgYXV0aG9yaXR5IGhvc3QuIFRoZSBiYXNpYyBwcm90b2NvbCBkYW5jZSBiZWdpbnMgd2l0 aCBhIHBhcmFtZXRlciBleGNoYW5nZSBmb2xsb3dlZCBieSBhIGNvb2tpZSBleGNoYW5nZSBh bmQgc2lnbiBleGNoYW5nZSwgYXMgcmVxdWlyZWQuIFRoZXNlIGV4Y2hhbmdlcyBwZXJmb3Jt IGEgZnVuY3Rpb24gc2ltaWxhciB0byB0aGUgVExTIGFuZCBEVExTIGhhbmRzaGFrZS4NCg0K SXQgaXMgaW1wb3J0YW50IHRvIG1pbmltaXplIHRoZSBudW1iZXIgb2YgZXhjaGFuZ2VzIGlu IG9yZGVyIHRvIG1pbmltaXplIHRoZSBsYXRlbmN5IHRvIGFjcXVpcmUgdGhlIHRpbWUgYW5k IGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyLiBPcmRpbmFyaWx5LCB0aGUgdGltZSBpcyBhY3F1 aXJlZCB3aXRoaW4gc2l4IE5UUCByb3VuZHMgb2YgdHdvIHNlY29uZHMgZWFjaC4gVGhlIGF1 dGhlbnRpY2F0aW9uIGRhbmNlIGlzIHBpZ2d5YmFja2VkIG9uIHRoZXNlIHJvdW5kcy4gSW4g dGhpcyBwcm9wb3NhbCB0aGUgYXV0aGVudGljaXR5IGNhbiBiZSBjb25maXJtZWQgd2l0aGlu IGZpdmUgcm91bmRzIG9yIGxlc3MuDQoNClRoZSBwYXJhbWV0ZXIgZXhjaGFuZ2UgaW5jbHVk ZXMgdGhlIHN1YmplY3QgbmFtZSBvbiB0aGUgaG9zdCBjZXJ0aWZpY2F0ZSwgYXMgd2VsbCBh cyB0aGUgYWxnb3JpdGhtcyBzZWxlY3RlZCBhbmQgb3RoZXIgcGFyYW1ldGVycy4gVGhlIGNv b2tpZSBleGNoYW5nZSBkZXZlbG9wcyBhbmQgdmVyaWZpZXMgdGhlIHNoYXJlZCBoYXNoIGtl eSBhbmQgc2lnbmF0dXJlLiBUaGUgcGFyYW1ldGVyIGFuZCBjb29raWUgZXhjaGFuZ2VzIGFy ZSBzZW50IHdpdGggaGFzaCBrZXkgemVyby4gVGhlIHNpZ24gZXhjaGFuZ2UgY29uc3RydWN0 cyBvciB2ZXJpZmllcyB0aGUgcHVibGljIGtleSBzaWduYXR1cmUgb24gdGhlIGhvc3QgY2Vy dGlmaWNhdGUuIFRoZSBhZ3JlZWQgaGFzaCBrZXkgZGV2ZWxvcGVkIGR1cmluZyB0aGUgY29v a2llIGV4Y2hhbmdlIGlzIHVzZWQgZm9yIHRoZSBzaWduIGV4Y2hhbmdlLCBhbmQgc3Vic2Vx dWVudCBudHAgcGFja2V0cy4NCg0KVGhlIGNlcnRpZmljYXRlIGF1dGhvcml0eSBob3N0IGlz IGRlc2lnbmF0ZWQgZWl0aGVyIGJ5IGEgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUgb3IgYnkg YW4gaWRlbnRpZmllciBpbiB0aGUgeDUwOXYzIGV4dGVuc2lvbiBmaWVsZC4gSG9zdCBjZXJ0 aWZpY2F0ZXMgYXJlIGV4Y2hhbmdlZCB1c2luZyB0aGUgY2VydGlmaWNhdGUgZXhjaGFuZ2Us IHdpdGggbmV3IGNlcnRpZmljYXRlcyByZXBsYWNpbmcgb2xkIG9uZXMgd2l0aCB0aGUgc2Ft ZSBzdWJqZWN0IGFuZCBpc3N1ZXIgbmFtZXMuIE5vdGUgdGhhdCB0aGUgY2VydGlmaWNhdGUg YXV0aG9yaXR5IGhvc3QgY2FuIGJlIGVpdGhlciB0aGUgcm9vdCBzZXJ2ZXIgaG9zdCBpbiB0 aGUgbmV0d29yayBvciBhbiBleHRlcm5hbCBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkgaG9zdCBj b25uZWN0ZWQgYnkgYW4gYXBwcm9wcmlhdGUgY29tbXVuaWNhdGlvbiBtZWFucy4NCg0KQnkg ZGVmYXVsdCwgdGhlIHN1YmplY3QgbmFtZSBvbiB0aGUgY2VydGlmaWNhdGUgaXMgdGhlIHN0 cmluZyByZXR1cm5lZCBieSB0aGUgVW5peCBnZXRob3N0YnluYW1lIGxpYnJhcnkgcm91dGlu ZS4gVGhlIHN1YmplY3QgbmFtZSBvbiB0aGUgY2VydGlmaWNhdGUgYXV0aG9yaXR5IGlzIGlu dGVycHJldGVkIGFzIHRoZSBncm91cCBuYW1lIGFzc29jaWF0ZWQgd2l0aCB0aGUgcGFydGlj dWxhciB0cmFpbCBhbmQgaXMgdXNlZnVsIGluIHRoZSBpZGVudGl0eSBleGNoYW5nZSBvciBl cXVpdmFsZW50IHNjaGVtZS4NCg0KVGhlIGNlcnRpZmljYXRlIHRyYWlsIGlzIGNvbnN0cnVj dGVkIHN0ZXAgYnkgc3RlcCBmb3IgZWFjaCBhc3NvY2lhdGlvbiwgd2l0aCB0aGUgaXNzdWVy IG5hbWUgcmVwbGFjaW5nIHRoZSBzdWJqZWN0IG5hbWUgYXQgZWFjaCBzdGVwLiBOb3RlIHRo YXQgZWFjaCBzdGVwIGludm9sdmVzIGEgc2luZ2xlIHNpZ25hdHVyZSwgc28gZG9lcyBub3Qg Y29uc3RydWN0IHRoZSBlbnRpcmUgdHJhaWwuDQoNCk9uY2UgdGhlIGNlcnRpZmljYXRlIHRy YWlsIGhhcyBiZWVuIHZlcmlmaWVkLCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIGRvIGl0IGFn YWluLCB1bmxlc3MgYSBjZXJ0aWZpY2F0ZSBpcyByZXZva2VkIG9yIHJlYWNoZXMgYWR2YW5j ZWQgYWdlLiBOb3RlIHRoYXQgZWFjaCBhc3NvY2lhdGlvbiBtaWdodCBoYXZlIGRpZmZlcmVu dCBpc3N1ZXIgYW5kIHN1YmplY3QgbmFtZXMuDQoNCkFzIHBhcnQgb2YgdGhlIGluaXRpYWxp emF0aW9uIHByb2Nlc3MsIGEgc2VsZi1zaWduZWQgaG9zdCBjZXJ0aWZpY2F0ZSBpcyBnZW5l cmF0ZWQgZm9yIHVzZSBieSBlYWNoIGFzc29jaWF0aW9uLiBJZiB0aGUgaG9zdCBjZXJ0aWZp Y2F0ZSBoYXMgbm90IGJlZW4gc2lnbmVkIGJ5IHRoZSBzZXJ2ZXIgZm9yIGVhY2ggYXNzb2Np YXRpb24sIHRoZSBob3N0IGNlcnRpZmljYXRlIGlzIHByb3ZpZGVkIHRvIGVhY2ggYXNzb2Np YXRpb24gc2VydmVyIGZvciBzaWduYXR1cmUuIFRoaXMgaXMgY2FsbGVkIHRoZSBzaWduIGV4 Y2hhbmdlIGFuZCBuZWVkcyB0byBiZSBkb25lIG9ubHkgb25jZSBmb3IgZWFjaCBhc3NvY2lh dGlvbi4gTm90ZSB0aGF0IHRoZSBuZXh0IGRvd25zdHJlYW0gaG9zdCBoYXMgdGhlIGNob2lj ZSBvZiBzaWduZWQgY2VydGlmaWNhdGVzLCBidXQgdGhleSBhcmUgYWxsIGVxdWl2YWxlbnQu DQoNCk9uY2UgdGhlIGNlcnRpZmljYXRlIHRyYWlsIHNpZ25hdHVyZXMgaGF2ZSBiZWVuIHZl cmlmaWVkLCB0aGUgaG9zdCBjZXJ0aWZpY2F0ZSBpcyBjb25zaWRlcmVkIGF1dGhlbnRpYywg dW5sZXNzIGEgY2VydGlmaWNhdGUgaGFzIGJlZW4gY2hhbmdlZC4gVGhlIHJlY292ZXJ5IHNj aGVtZSB0byB1cGRhdGUgdGhlIGNlcnRpZmljYXRlIHRyYWlsIGNvdWxkIGJlIHRlZGlvdXMs IGFzIGRlc2NyaWJlZCBiZWxvdy4gTm90ZSB0aGF0IHRoZXJlIGFyZSBubyBwcm92aXNpb25z IGluIHRoZSBzZWN1cml0eSBzY2hlbWUgdG8gcmV2b2tlIGEgY2VydGlmaWNhdGUsIHNvIHRo aXMgbXVzdCBiZSBkb25lIGJ5IGV4dGVybmFsIG1lYW5zLg0KDQpJbiB0aGUgZm9sbG93aW5n LCB0aGUgaG9zdCBjZXJ0aWZpY2F0ZSBiZWxvbmdzIHRvIHRoZSBob3N0IGNvbnRhaW5pbmcg dGhlIHB1YmxpYy9wcml2YXRlIGtleXMsIHdoaWxlIGEgc2VydmVyIGNlcnRpZmljYXRlIGJl bG9uZ3MgdG8gZWFjaCBhc3NvY2lhdGlvbiBzZXBhcmF0ZWx5LiBPbmNlIHRoZSBjb29raWUg ZXhjaGFuZ2UgaGFzIGNvbXBsZXRlZCwgdGhlIHNoYXJlZCBoYXNoIGtleSBjYW4gYmUgdXNl ZCBmb3IgYXV0aGVudGljYXRpb24gb2YgYWxsIHN1YnNlcXVlbnQgcGFja2V0cy4NCg0KRm9y IHRoaXMgcHVycG9zZSwgdGhlIGNvb2tpZSBleGNoYW5nZSBpcyBzcGxpdCBpbnRvIHR3byBw aGFzZXM6IHRoZSBhZ3JlZW1lbnQgcGhhc2UsIHdoaWNoIGRldmVsb3BzIHRoZSBzaGFyZWQg aGFzaCBrZXksIGFuZCB0aGUgYXV0aGVudGljYXRpb24gcGhhc2UsIHdoaWNoIGF1dGhlbnRp Y2F0ZXMgdGhlIHNoYXJlZCBoYXNoIGtleS4gSWYgbmVjZXNzYXJ5LCBUaGUgY2VydGlmaWNh dGUgZXhjaGFuZ2Ugb2J0YWlucyB0aGUgc2VydmVyIGNlcnRpZmljYXRlcyBiZWZvcmUgdGhl IGF1dGhlbnRpY2F0aW9uIHBoYXNlLiBPcmRpbmFyaWx5LCB0aGUgY2VydGlmaWNhdGUgZXhj aGFuZ2UgbmVlZHMgdG8gYmUgZG9uZSBvbmx5IG9uY2UsIHVubGVzcyBhIGNlcnRpZmljYXRl IGlzIGNoYW5nZWQuIEVhY2ggcGhhc2UgaXMgcmVwcmVzZW50ZWQgYnkgYW4gZXhjaGFuZ2Ug b2YgdGhlIHNhbWUgbmFtZS4NCg0KSW4gc3ltbWV0cmljIG1vZGUgdGhlIGFncmVlbWVudCBw aGFzZSB1c2VzIHRoZSBjbGFzc2ljIERpZmZpZS1IZWxsbWFuIGFsZ29yaXRobS4gSW4gY2xp ZW50L3NlcnZlciBtb2RlIHRoZSBrZXkgaXMgYSBjb29raWUsIGFzIGRlc2NyaWJlZCBiZWxv dy4gSW4gdGhpcyBwaGFzZSBhbmQgdGhlIHBhcmFtZXRlciBleGNoYW5nZSwgdGhlIGV4Y2hh bmdlIHVzZXMga2V5IHplcm8sIGFzIGRlc2NyaWJlZCBhYm92ZS4gVGhlIGF1dGhlbnRpY2F0 aW9uIHBoYXNlIGNvbnNpc3RzIG9mIGFuIGV4Y2hhbmdlIG9mIGhhc2gga2V5IHNpZ25hdHVy ZXMuDQoNClRoZSBhc3NvY2lhdGlvbiBpcyBjb25zaWRlcmVkIHByb3Zpc2lvbmFsbHkgYXV0 aGVudGljIGZvbGxvd2luZyB0aGUgYXV0aGVudGljYXRpb24gcGhhc2Ugb2YgdGhlIGNvb2tp ZSBleGNoYW5nZS4gVGhlIHNpZ25hdHVyZSB0cmFpbCBpcyBhdWdtZW50ZWQgaW4gdGhlIHNp Z24gZXhjaGFuZ2UuIElmIHN1Y2Nlc3NmdWwsIHRoZSBjZXJ0aWZpY2F0ZSB0cmFpbCBpcyBl eHRlbmRlZCBieSBvbmUgc3RlcDsgaWYgbm90LCB0aGUgYXNzb2NpYXRpb24gdHJpZXMgYWdh aW4gYWZ0ZXIgdGltZW91dC4NCg0KVGhlIHNlcXVlbmNlIG9mIG1lc3NhZ2VzIGluIHRoZSBw cm90b2NvbCBkYW5jZSBjYW4gYmVzdCBiZSBtYW5hZ2VkIGJ5IGFwcHJvcHJpYXRlIHN0YXRl IHRyYW5zaXRpb24gdGFibGVzLiBUaGVzZSBkYW5jZXMgYXJlIHNpbWlsYXIsIGJ1dCBub3Qg aWRlbnRpY2FsLCB0byB0aGUgb25lcyB1c2VkIGZvciBzaW1pbGFyIHB1cnBvc2VzIGluIHRo ZSBSRkM1OTA2IEF1dG9rZXkgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBOVFMgcHJvcG9zYWxz Lg0KDQpBIHN1YnRsZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhpcyBwcm9wb3NhbCBhbmQgdGhl IE5UUyBwcm9wb3NhbHMgaXMgaG93IHRvIGludGVycHJldCB0aGUgcGFyYW1ldGVyIGV4Y2hh bmdlIGRhdGEuIFRoZSBpbnRlbnQgaXMgdGhhdCBlYWNoIHBlZXIvY2xpZW50IGhhcyBhIHBy aXZhdGUgdmVjdG9yIG9mIGNvbXBvbmVudHMsIHdoaWxlIGVhY2ggcGVlci9zZXJ2ZXIgaGFz IGEgdmVjdG9yIG9mIHNpbWlsYXIgY29tcG9uZW50cy4gVGhlIHBhcmFtZXRlciBleGNoYW5n ZSBhcHBlbmRzIHRoZSB2ZWN0b3Igb2Ygb25lIHBhcnRpY2lwYW50IHRvIHRoZSB2ZWN0b3Ig b2YgdGhlIG90aGVyIHBhcnRpY2lwYW50LiBUaGVuLCB0aGUgd29ya2luZyB2ZWN0b3IgaXMg ZGVyaXZlZCBpbiBlYWNoIHBhcnRpY2lwYW50IGJ5IHRoZSBzYW1lIGFsZ29yaXRobS4gVGhl IHJlc3VsdCBhcHBsaWVzIHRvIGJvdGggc3ltbWV0cmljIGFuZCBjbGllbnQvc2VydmVyIG1v ZGVzLCBhbHRob3VnaCB0aGUgcmVzdWx0cyBhcmUgbm90IHNhdmVkIGluIHNlcnZlciBtb2Rl LiBBIHZlY3RvciBjb21wb25lbnQgY29uc2lzdHMgb2YgdHVwbGVzIG9mIHJhbmsvTklEIHZh bHVlcyBvciBhbnl0aGluZyBlbHNlIHRoYXQgY2FuIGJlIHJlcHJlc2VudGVkIGluIEFTTi4x IGVuY29kaW5nLg0KDQpUaGUgY2hvaWNlIG9mIGRhbmNlIGlzIGRldGVybWluZWQgYnkgdGhl IE5UUCBtb2RlOiBjbGllbnQvc2VydmVyLCBzeW1tZXRyaWMgYW5kIGJyb2FkY2FzdC4gVGhl IGFib3ZlIHNlcXVlbmNlIG9mIGV4Y2hhbmdlcyBpcyBpZGVudGljYWwgZm9yIGNsaWVudC9z ZXJ2ZXIgYW5kIHN5bW1ldHJpYyBtb2RlcywgYXMgd2VsbCBhcyBvcHRpb25hbCBicm9hZGNh c3QgZGVsYXkgbWVhc3VyZW1lbnQsIGlmIHVzZWQuIE5vdGUgdGhhdCB0aGUgc2lnbmF0dXJl IHNjaGVtZSBpcyBkZWZpbmVkIG9uIGVhY2ggY2VydGlmaWNhdGUuIE90aGVyd2lzZSwgdGhl IGFncmVlbWVudCwgaGFzaCwgc2lnbmF0dXJlIGFuZCBlbmNyeXB0aW9uIGFsZ29yaXRobSBp ZGVudGlmaWVycyBkZWZhdWx0IGFzIGluIHRoZSBwYXJhbWV0ZXIgZXhjaGFuZ2UuDQoNCkEg c3VidGxlIGNvbXBsaWNhdGlvbiBpcyBob3cgdG8gdmFsaWRhdGUgdGhlIGxpZmV0aW1lIG9m IHRoZSBjZXJ0aWZpY2F0ZXMgYWxvbmcgdGhlIHRyYWlsIHRvIHRoZSBjZXJ0aWZpY2F0ZSBh dXRob3JpdHkuIFRoZSBsaWZldGltZSBvZiB0aGUgc3ViamVjdCBjZXJ0aWZpY2F0ZSBpbnRl cnNlY3RlZCB3aXRoIHRoZSBsaWZldGltZSBvZiB0aGUgaXNzdWVyIGNlcnRpZmljYXRlIG1p Z2h0IG9yIG1pZ2h0IG5vdCBiZSBlbXB0eS4gSG93ZXZlciwgdGhlIGxpZmV0aW1lIG9mIHRo ZSBzZXJ2ZXIgY2VydGlmaWNhdGUgbXVzdCBjb250YWluIHRoZSBjdXJyZW50IHZhbGlkIHRp bWUuDQoNClRoZSBvcnRob2RveCB3YXkgaXMgdG8gd2FpdCB1bnRpbCB0aGUgYXNzb2NpYXRp b24gdGltZSBpcyB2YWxpZCwgdGhlbiBjb21wYXJlIHRoZSB2YWxpZCB0aW1lIHdpdGggdGhl IGNlcnRpZmljYXRlIGxpZmV0aW1lLiBBIGRpc2NyZXBhbmN5IHJlc3VsdHMgaW4gYSBwcm90 b2NvbCByZXN0YXJ0LiBOb3RlIHRoYXQgYSBuZXcgcmVnZW5lcmF0ZWQgY2VydGlmaWNhdGUg bWlnaHQgcmVxdWlyZSBhIG5ldyBnZW5lcmF0aW9uIG9mIGl0cyBpc3N1ZXIuIFRoZSBpbXBs aWNhdGlvbnMgbWF5IGJlIHRlZGlvdXMuDQoNClRoZSBkYW5jZXMgaW52b2x2ZSBhIGJhbGFu Y2UgYmV0d2VlbiBmb3JtYWwgYXV0aGVudGljYXRpb24gYW5kIGR1cmF0aW9uIG9mIHRoZSBw cm90b2NvbC4gRm9yIGluc3RhbmNlLCB0aGUgY29va2llIGV4Y2hhbmdlIGNvbmZpcm1zIHRo YXQgdGhlIGhhc2gga2V5IGlzIHZhbGlkLCBidXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgY29u ZmlybSB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSB0cmFpbCBpcyB2YWxpZC4gQSBzdWNjZXNzZnVs IHNpZ25hdHVyZSBvZiB0aGUgaG9zdCBjZXJ0aWZpY2F0ZSBjb25maXJtcyB0aGF0IHRoZSBo b3N0IGNlcnRpZmljYXRlIGlzIHZhbGlkLiBUaGVyZSBpcyBhbiBpbnRlcnZhbCBiZXR3ZWVu IHZhbGlkYXRpb24gb2YgdGhlIHNoYXJlZCBoYXNoIGtleSBhbmQgdmFsaWRhdGlvbiBvZiB0 aGUgY2VydGlmaWNhdGUgdHJhaWwgYnV0IHRoZSB0aW1lIGluZm9ybWF0aW9uIG1heSBvciBt YXkgbm90IGJlIGNvcnJlY3QuDQoNCk5vdGUgdGhhdCBlYWNoIGdlbmVyYXRpb24gb2YgdGhl IGRhbmNlIHJlc3VsdHMgaW4gYSBuZXcgc2hhcmVkIGhhc2gga2V5IHVucmVsYXRlZCB0byB0 aGUgbGFzdCBzaGFyZWQgaGFzaCBrZXkuIEluIHRoaXMgc2Vuc2UsIHRoZSBwcm90b2NvbCBo YXMgcGVyZmVjdCBmb3J3YXJkIHNlY3JlY3kuDQoNCjguNC4xIFN5bW1ldHJpYyBNb2RlDQoN ClRoZSBnb2FsIG9mIHRoaXMgZGFuY2UgaXMgdG8gaW5zdGFsbCBpZGVudGljYWwgc2hhcmVk IGhhc2gga2V5cyBpbiBib3RoIHBlZXJzLiBUaGUgZGFuY2UgY2FuIGJlIHN0YXJ0ZWQgYnkg ZWl0aGVyIHBlZXIuIFBlZXJzIEFsaWNlIGFuZCBCb2IgdXNlIGxhcmdlIHByaW1lIHAgYXMg bW9kdWx1cyBhbmQgcHJpbWl0aXZlIHJvb3QgZyBhcyBnZW5lcmF0b3IuIEEgc21hbGwgdmFs dWUgZm9yIGcsIHR5cGljYWxseSAyLCBpcyBvZnRlbiB1c2VkLg0KDQpJbiB0aGUgYWdyZWVt ZW50IHBoYXNlLCBBbGljZSBzZW5kcyBoZXIgcHVibGljIERIIGtleSB0byBCb2IgaW4gYW4g ZXh0ZW5zaW9uIGZpZWxkIG9mIGEgcmVxdWVzdCBtZXNzYWdlLiBCb2IgY29uc3RydWN0cyBo aXMgcHVibGljIERIIGtleSBhbmQgc2VuZHMgaXQgdG8gQWxpY2UgaW4gYW4gZXh0ZW5zaW9u IGZpZWxkIG9mIGEgcmVzcG9uc2UgbWVzc2FnZS4gQm90aCBBbGljZSBhbmQgQm9iIHRoZW4g Y29uc3RydWN0IHRoZSBzaGFyZWQgaGFzaCBrZXkgZm9yIHVzZSBsYXRlci4NCg0KSW4gdGhl IGF1dGhlbnRpY2F0aW9uIHBoYXNlLCBBbGljZSBzZW5kcyBoZXIgc2lnbmF0dXJlIG9mIHRo ZSBzaGFyZWQgaGFzaCBrZXkgdG8gQm9iLiBCb2IgdmVyaWZpZXMgdGhlIHNpZ25hdHVyZSwg dGhlbiBzZW5kcyBoaXMgc2lnbmF0dXJlIG9mIHRoZSBzaGFyZWQgaGFzaCBrZXkgdG8gQWxp Y2UuIEFsaWNlIHZlcmlmaWVzIGhpcyBzaWduYXR1cmUuIEZhaWx1cmUgdG8gdmFsaWRhdGUg ZWl0aGVyIHNpZ25hdHVyZSByZXN1bHRzIGluIGEgY3J5cHRvLU5BSyBhbmQgcHJvdG9jb2wg cmVzdGFydC4NCg0KVGhlIHNoYXJlZCBrZXkgY29uc3RydWN0ZWQgYnkgQWxpY2UgYW5kIEJv YiBpcyB1c2VkIGFzIHRoZSBoYXNoIGtleSBpbiBzdWJzZXF1ZW50IG1lc3NhZ2VzLiBUaGUg cHVibGljIGFuZCBwcml2YXRlIERIIGtleXMgYXJlIGV4cHVuZ2VkIGFmdGVyIHVzZTsgdGhl eSBhcmUgdXNlZCBvbmx5IG9uY2UuDQoNCjguNC4yIENsaWVudC9TZXJ2ZXIgTW9kZQ0KDQpU aGUgZ29hbCBpbiB0aGlzIGRhbmNlIGlzIHRvIGluc3RhbGwgYSBzZXJ2ZXIgY29va2llIHVz ZWQgaW4gdGhlIGNsaWVudCBhcyB0aGUgaGFzaCBrZXkuIFRoZSBkYW5jZSBpcyBzdGFydGVk IGJ5IHRoZSBjbGllbnQuIFRoZSBjb29raWUgY2FuIGJlIHJlZ2VuZXJhdGVkIGJ5IHRoZSBz ZXJ2ZXIgdXBvbiBhcnJpdmFsIG9mIGEgY2xpZW50IHBhY2tldC4gVGhlIGNvb2tpZSBleGNo YW5nZSBpcyBzaW1pbGFyIHRvIHRoZSBjb29raWUgZXhjaGFuZ2UgcHJvcG9zZWQgaW4gdGhl IE5UUyBkb2N1bWVudHMsIGV4Y2VwdCB0aGF0IHRoZSBwcm9wb3NlZCBjb29raWUgZXhjaGFu Z2UgaXMgcHJvdGVjdGVkIGJ5IGtleSB6ZXJvIGFuZCB0aGUgb24td2lyZSBwcm90b2NvbCBs YXllci4NCg0KSW4gdGhlIGFncmVlbWVudCBwaGFzZSwgY2xpZW50IEFsaWNlIHNlbmRzIGhl ciBwdWJsaWMgREgga2V5IHRvIHNlcnZlciBCb2IuIEJvYiB0aGVuIHNlbmRzIGhpcyBwdWJs aWMgREgga2V5IHRvIEFsaWNlLiBCb3RoIEFsaWNlIGFuZCBCb2IgY29uc3RydWN0IHRoZSBz aGFyZWQga2V5IGFzIGRlc2NyaWJlZCBhYm92ZS4gQWxpY2UgYW5kIEJvYiB1c2UgdGhlIHNo YXJlZCBrZXkgYXMgdGhlIGVuY3J5cHRpb24ga2V5IHVzZWQgbGF0ZXIuDQoNClRoZSBjb29r aWUgaXMgdGhlIGhhc2ggb2YgdGhlIGNsaWVudCBJUCBhZGRyZXNzZXMgY29uY2F0ZW5hdGVk IHdpdGggYSBzZXJ2ZXIgc2VjcmV0IGtleSB1c2luZyB0aGUgc2VsZWN0ZWQgaGFzaCBhbGdv cml0aG0uIFRoZSBzZXJ2ZXIgc2VjcmV0IGtleSBpcyBhIHJhbmRvbSBudW1iZXIgcmVnZW5l cmF0ZWQgYWJvdXQgb25jZSBwZXIgZGF5LiBCb2IgZW5jcnlwdHMgdGhlIGNvb2tpZSB1c2lu ZyB0aGUgc2hhcmVkIGtleSBhbmQgc2VuZHMgaXQgaW4gdGhlIHNhbWUgcGFja2V0IGFzIGhp cyBESCBwdWJsaWMga2V5Lg0KDQpUaGUgYXV0aGVudGljYXRpb24gcGhhc2UgdXNlcyB0aGUg c2FtZSBzaWduYXR1cmVzIGFzIGluIHRoZSBzeW1tZXRyaWMgbW9kZS4gQXMgYW4gb3B0aW9u YWwgZW1iZWxsaXNobWVudCwgaWYgdGhlIHNlcnZlciBoYXMgdGhlIHB1YmxpYyBjZXJ0aWZp Y2F0ZSBvZiB0aGUgY2xpZW50LCB0aGlzIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCB0byB0 aGUgc2VydmVyIGFzIHdlbGwuDQoNCkFzIGFuIG9wdGlvbmFsIGZlYXR1cmUsIGEgbm9uY2Ug Y2FuIGJlIGNvbmNhdGVuYXRlZCB3aXRoIHRoZSBjb29raWUgYW5kIHRoZSB3b3JraW5nIGNv b2tpZSBhcyB0aGUgaGFzaCBvZiB0aGUgcmVzdWx0LiAgVGhlIHRyYW5zbWl0IHRpbWVzdGFt cCBjYW4gYmUgdXNlZCBhcyB0aGUgbm9uY2UuIFRoaXMgIG1ha2VzIGVhY2ggaGFzaCBrZXkg ZGlmZmVyZW50LCBmdXJ0aGVyIGNvbXByb21pc2luZyBhIGJydXRlIGZvcmNlIGF0dGFjay4N Cg0KOC40LjMgQnJvYWRjYXN0IE1vZGUNCg0KVGhlIG9yaWdpbmFsIEF1dG9rZXkgcHJvdG9j b2wgd2FzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGNyeXB0b2dyYXBoaWMg YWxnb3JpdGhtcyB3ZXJlIHZlcnkgc2xvdyBhbmQgdnVsbmVyYWJsZSB0byBhIGZsb29kaW5n IGF0dGFjay4gSW4gZmFjdCwgdGhlIERpZmZpZS1IZWxsbWFuIGFncmVlbWVudCB0b29rIG92 ZXIgMTAgc2Vjb25kcyBvbiBhIFN1biBJUEMuIEFzIGN1cnJlbnQgbWFjaGluZXMgYW5kIGFs Z29yaXRobXMgYXJlIG11Y2ggZmFzdGVyLCBpdCBpcyBjb252ZW5pZW50IGZvciB0aGUgc2Vy dmVyIHRvIGNvbXB1dGUgdGhlIHNpZ25hdHVyZSBvZiB0aGUgTlRQIGhlYWRlciBpbiBhbiBl eHRlbnNpb24gZmllbGQgYW5kIGZvciB0aGUgY2xpZW50IHRvIHZlcmlmeSB0aGUgc2lnbmF0 dXJlIHVzaW5nIHRoZSBwdWJsaWMga2V5IG9uIHRoZSBzZXJ2ZXIgY2VydGlmaWNhdGUuIFRo ZSBzZXJ2ZXIgY2VydGlmaWNhdGUgbXVzdCBiZSBpbnN0YWxsZWQgYmVmb3JlaGFuZCBpbiBl YWNoIGNsaWVudC4gVGhpcyBpcyBub3QgYSB0cml2aWFsIHJlcXVpcmVtZW50OyB0aGUgY2Vy dGlmaWNhdGUgdHJhaWwgbXVzdCBiZSBjb25zdHJ1Y3RlZCBzZXBhcmF0ZWx5Lg0KDQpXaGVu IHR3byBvciBtb3JlIGJyb2FkY2FzdCBjbGllbnQgYXNzb2NpYXRpb25zIGFyZSBpbiB0aGUg c2FtZSBob3N0LCBpdCBpcyBjb252ZW5pZW50IHRvIGluY2x1ZGUgdGhlIGNlcnRpZmljYXRl IHN1YmplY3QgbmFtZSBpbiBhbiBleHRlbnNpb24gZmllbGQgb2YgdGhlIGJyb2FkY2FzdCBw YWNrZXQuIFRoaXMgc2VsZWN0cyB0aGUgc2VydmVyIGNlcnRpZmljYXRlIGFuZCB0aHVzIHRo ZSBjb3JyZWN0IHNpZ25hdHVyZSBrZXkuDQoNCkEgY29tbW9uIHByb2JsZW0gaW4gdGhpcyBh bmQgb3RoZXIgYnJvYWRjYXN0IHNjaGVtZXMgaXMgdnVsbmVyYWJpbGl0eSB0byBjb3BpZXMg b2Ygb2xkIG1lc3NhZ2VzLCBwZXJoYXBzIHZlcnkgb2xkIG9uZXMuIFRoZSBwcm9wb3NlZCBz b2x1dGlvbiBpcyB0byB1c2UgdGhlIHRyYW5zbWl0IHRpbWVzdGFtcCBhcyBhIHNlcXVlbmNl IG51bWJlciBhbmQgb3JkZXJpbmcgZnVuY3Rpb24uIEFuIG9sZCBkdXBsaWNhdGUgaXMgcmVj b2duaXplZCBieSBhIHRyYW5zbWl0IHRpbWVzdGFtcCBvbGRlciB0aGFuIHRoZSBtb3N0IHJl Y2VudCB0cmFuc21pdCB0aW1lc3RhbXAuIE9uY2UgdGhlIGZpcnN0IHBhY2tldCBpcyByZWNl aXZlZCwgdGhlIGJyb2FkY2FzdCBjbGllbnQgaWdub3JlcyBhbGwgYnJvYWRjYXN0IHBhY2tl dHMgd2l0aCBhbiBlYXJsaWVyIHRyYW5zbWl0IHRpbWVzdGFtcC4gVGhpcyBkZXNpZ24gd29y a3MgZXZlbiBpZiB0aGUgYnJvYWRjYXN0IHNlcnZlciBpcyByZXN0YXJ0ZWQuIElmIGEgYnJv YWRjYXN0IGNsaWVudCBpcyByZXN0YXJ0ZWQsIHRoZXJlIG1pZ2h0IGJlIHNvbWUgc3B1cmlv dXMgb2xkIGR1cGxpY2F0ZXMgYmVmb3JlIHRoZSBmaXJzdCBuZXcgbWVzc2FnZS4gSWYgdGhl IG1vc3QgcmVjZW50IHRyYW5zbWl0IHRpbWVzdGFtcCBpcyBwcmVzZXJ2ZWQgYmV0d2VlbiBy ZXN0YXJ0cywgdGhlc2Ugb2xkIGR1cGxpY2F0ZXMgYXJlIHN1cHByZXNzZWQuDQoNCjkuIEVy cm9yIFJlY292ZXJ5DQoNCjkuMSBCcnV0ZSBGb3JjZSBBdHRhY2tzDQoNCkFzIGluIGFsbCBj cnlwdG9ncmFwaGljIGFsZ29yaXRobXMsIHRoZSBzZWNyZXQga2V5cyBjYW4gYmUgY29tcHJv bWlzZWQgd2l0aCBwb3NzaWJseSBnaWdhbnRpYyBjb21wdXRpbmcgcmVzb3VyY2VzLiBPbmUg b2YgdGhlIGZpcnN0IHRoaW5ncyBhIHN1c3BpY2lvdXMgY3J5cHRvZ3JhcGhlciBsb29rcyBh dCBpcyB0aGUgc2l6ZSBvZiB0aGUgYml0IHN0cmluZ3MgdXNlZCBpbiB0aGUgY3J5cHRvZ3Jh cGhpYyBzY2hlbWUuDQoNCkEgYnJ1dGUgZm9yY2UgYXR0YWNrIG9uIHRoZSBzaGFyZWQgaGFz aCBrZXkgbWlnaHQgbm90IHdvcmsgaW4gYWxsIGNhc2VzLiBDb25zaWRlciB0aGUgbnVtYmVy IGsgb2Ygc3B1cmlvdXMga2V5cyB0aGF0IGNvcnJlY3RseSBkZWNyeXB0IGEgY2lwaGVydGV4 dCBvZiBuIHN5bWJvbHMuIFRoZSBudW1iZXIgayBnZW5lcmFsbHkgZGVjcmVhc2VzIGFzIG4g aW5jcmVhc2VzLiBUaGUgbnVtYmVyIG9mIHN5bWJvbHMgbiB3aGVyZSBrIGRlY3JlYXNlcyB0 byBvbmUgaXMgY2FsbGVkIHRoZSB1bmljaXR5IGRpc3RhbmNlLiBJZiB0aGUgcGFja2V0IGxl bmd0aCBpcyBsZXNzIHRoYW4gdGhlIHVuaWNpdHkgZGlzdGFuY2UsIHRoaXMgbWVhbnMgdGhh dCBhIGtleSB0aGF0IGNvcnJlY3RseSBkZWNyeXB0cyBhIGNpcGhlcnRleHQgeCBtYXkgbm90 IGNvcnJlY3RseSBkZWNyeXB0IGEgY2lwaGVydGV4dCBvdGhlciB0aGFuIHguDQoNCjkuMiBD cnlwdG9ncmFwaGljIEVycm9ycw0KDQpUaGUgdXN1YWwgcmVzcG9uc2UgdG8gYSBoYXNoIG9y IHNpZ25hdHVyZSBmYWlsdXJlIGluIHN5bW1ldHJpYyBhbmQgc2VydmVyIG1vZGVzIGlzIHRv IHNlbmQgYSBjcnlwdG8tTkFLIGFuZCBkaXNjYXJkIHRoZSBwYWNrZXQuIFRoZSBjcnlwdG8t TkFLIGlzIG5vdCB1c2VkIGluIGNsaWVudCBvciBicm9hZGNhc3QgbW9kZXMuDQoNCklmIHRo ZSBjcnlwdG8tTkFLIHJlc3VsdHMgZnJvbSBhIGhhc2ggZmFpbHVyZSwgb25seSB0aGUgY29v a2llIGV4Y2hhbmdlIGlzIG5lY2Vzc2FyeS4gSWYgdGhlIGNyeXB0by1OQUsgcmVzdWx0cyBm cm9tIGEgc2lnbmF0dXJlIGZhaWx1cmUsIHRoZSBwcm90b2NvbCBpcyByZXN0YXJ0ZWQuDQoN CkFsbCBtZXNzYWdlcywgaW5jbHVkaW5nIHRoZSBjcnlwdG8tTkFLLCBhcmUgdmFsaWRhdGVk IGJ5IHRoZSB0ZXN0cyBvZiB0aGUgb24td2lyZSBwcm90b2NvbC4gSW4gYWRkaXRpb24sIGFs bCBtZXNzYWdlcyBhZnRlciB0aGUgY29va2llIGV4Y2hhbmdlIGFyZSBwcm90ZWN0ZWQgYnkg dGhlIGFncmVlZCBoYXNoIGtleSBhbmQgaGFzaCBhbGdvcml0aG0uDQoNCjkuMyBPbGQgRHVw bGljYXRlcw0KDQpPbGQgZHVwbGljYXRlcyBhcmUgc3VwcHJlc3NlZCBpbiB2YXJpb3VzIHdh eXMsIGV2ZW4gaWYgbm90IGF1dGhlbnRpY2F0ZWQuICBUaGUgdHJhbnNtaXQgdGltZXN0YW1w IHRlc3Qgc3VwcHJlc3NlcyByZXBsYXlzIG9mIHRoZSBsYXN0IHRyYW5zbWl0dGVkIHBhY2tl dC4gIFRoZSBsb29wYmFjayB0ZXN0IHN1cHByZXNzZXMgcmVwbGF5cyBvZiBvbGQgbWVzc2Fn ZXMsIGJvdGggaW4gc3ltbWV0cmljIGFuZCBjbGllbnQvc2VydmVyIG1vZGUuDQoNClRvIHNl ZSB0aGlzLCBjb25zaWRlciBhIHJlcGxheSBvZiBhbiBvbGQgcGFja2V0IGZyb20gcGVlciBB IHRvIHBlZXIgQiBpbiBzeW1tZXRyaWMgbW9kZS4gQXNzdW1lIHRoYXQgdGhlIG9sZCByZXBs YXkgYXJyaXZlcyBhdCBwZWVyIEIgYWZ0ZXIgdGhlIGxhc3QgbGVnaXRpbWF0ZSBwYWNrZXQg ZnJvbSBwZWVyIEEgYW5kIGJlZm9yZSB0aGUgbmV4dCB0cmFuc21pdHRlZCBwYWNrZXQgZnJv bSBwZWVyIEIuIFRoZSBsb29wYmFjayB0ZXN0IGZvciBwZWVyIEIgb3BlcmF0ZXMgYXMgZm9y IHBlZXIgQSB0byBkaXNjYXJkIHRoZSBvbGQgcmVwbGF5Lg0KDQo5LjQgR2VuZXJhbCBDb25z aWRlcmF0aW9ucw0KDQpUaGVyZSBpcyBhIHdpZGUgc3BlY3RydW0gb2YgcG9zc2libGUgaG9z dGlsZSBwcm9iZXMgb24gdGhlIE5UUCBpbXBsZW1lbnRhdGlvbiBpdHNlbGYuIE9uZSBvZiB0 aGVzZSBpcyBzaW1wbHkgdG8gYW1wdXRhdGUgdGhlIGNyeXB0b2dyYXBoaWMgZGF0YSBmcm9t IGEgdHJhbnNtaXR0ZWQgcGFja2V0LiBBbiBpbW1hdHVyZSBpbXBsZW1lbnRhdGlvbiBtaWdo dCBhc3N1bWUgdGhhdCB0aGUgTlRQIGRlc2lnbiBwZXJtaXRzIGJvdGggc2VjdXJlIGFuZCB1 bnNlY3VyZSBvcGVyYXRpb25zIHRvIGJlIHNhbmN0aW9uZWQuIFN1Y2ggYW4gZXJyb3IgaW52 aXRlcyBhIG1pZGRsZW1hbiB0byBzaWduaWZpY2FudGx5IGFsdGVyIHRoZSByZWNlaXZlIGFu ZCB0cmFuc21pdCB0aW1lc3RhbXBzIG9uIHRoZSBOVFAgcGFja2V0LCByZXN1bHRpbmcgaW4g YW55IG9mIHRoZSBhY3Rpb25zIGRlc2NyaWJlZCBiZWxvdy4NCg0KQSBwcm90b2NvbCByZXN0 YXJ0IGlzIGluaXRpYXRlZCB1cG9uIHJlY2VpcHQgb2YgYSB2YWxpZCBjcnlwdG8tTkFLIGlu IHJlc3BvbnNlIHRvIGEgc2lnbmF0dXJlIGZhaWx1cmUgb3IgcHJvdG9jb2wgZXJyb3IuIEEg Y3J5cHRvLU5BSyByZXN1bHRpbmcgZnJvbSBhIGhhc2ggZmFpbHVyZSBvcmRpbmFyaWx5IHJl c3VsdHMgaW4gb25seSBhIGNvb2tpZSBleGNoYW5nZS4NCg0KSW4gc3ltbWV0cmljIG1vZGUg ZWFjaCByZXN0YXJ0IHJlc3VsdHMgaW4gYSBkaWZmZXJlbnQgc2hhcmVkIGhhc2gga2V5LiBJ biBjbGllbnQvc2VydmVyIG1vZGUsIHRoZSBzaGFyZWQgaGFzaCBrZXkgaXMgY2hhbmdlZCBv bmx5IHdoZW4gdGhlIHNlcnZlciBzZWNyZXQgdmFsdWUgaXMgY2hhbmdlZCBvciB3aGVuIHRo ZSBvcHRpb25hbCBub25jZSBpcyB1cGRhdGVkLiBUaGUgcmVzdGFydCB0aGVuIGRlbGF5cyBh IHRpbWUgaW50ZXJ2YWwgcmFuZG9taXplZCBvdmVyIHRoZSBwb2xsIGludGVydmFsLCB0aGVu IHNlbmRzIGEgcGFyYW1ldGVyIGV4Y2hhbmdlIGFuZCBjb250aW51ZXMgdGhlIGRhbmNlLg0K DQpUaGlzIGRlc2lnbiBwcm92aWRlcyBjb3JyZWN0IHJlY292ZXJ5IGluIGNhc2Ugb2YgcHVi bGljIGtleSBjaGFuZ2VzIGFuZCBzZXJ2ZXIgc2VjcmV0IGtleSB1cGRhdGVzLiBXaGlsZSB0 aGlzIHNjaGVtZSBpbnZpdGVzIGEgdGVycm9yaXN0IHRvIGRpc3J1cHQgdGhlIHByb3RvY29s IGJ5IGluamVjdGluZyBhIGJvZ3VzIHBhcmFtZXRlciBleGNoYW5nZSBpbiB0aGUgbWlkZGxl IG9mIG9yZGluYXJ5IG9wZXJhdGlvbnMsIHRoZSBjaG9pY2Ugb2Yga2V5IHplcm8gcHJvdGVj dHMgdGhlIGhhbmRzaGFrZSBmcm9tIGZvcmVpZ24gbmV0d29ya3Mgd2l0aG91dCBrbm93bGVk Z2Ugb2YgdGhlIGtleSB6ZXJvIHZhbHVlLiBUaGUgcmVzdWx0IG1heSBub3QgYmUgYSB2dWxu ZXJhYmlsaXR5LCBidXQgaW4gYW55IGNhc2UgcmVwcmVzZW50cyBhIGRlbmlhbCBvZiBzZXJ2 aWNlIGF0dGFjay4NCg0KOS41IFByb3RvY29sIEVycm9ycw0KDQpUaGUgcmFuZG9tIGRlbGF5 IGF0IHByb3RvY29sIHJlc3RhcnQgaXMgZGVzaWduZWQgdG8gbWluaW1pemUgY29sbGlzaW9u cyBpbiBzeW1tZXRyaWMgbW9kZS4gQSBzaW1wbGUgYWxnb3JpdGhtIGlzIHVzZWQgaW4gdGhl IHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiB0byBzbGV3IHRoZSBwYWNrZXRzIG9mIG9uZSBw ZWVyIHRvIGJlIHRyYW5zbWl0dGVkIG5lYXIgdGhlIG1pZHBvaW50IG9mIHRoZSBvdGhlciBw ZWVy4oCZcyBwb2xsIGludGVydmFsLg0KDQpJbiBzeW1tZXRyaWMgbW9kZSB0aGUgZmlyc3Qg cGVlciB0byB0aW1lb3V0IGFmdGVyIHJlc3RhcnQgc2VuZHMgYSBwYXJhbWV0ZXIgcmVxdWVz dCBhbmQgY29udGludWVzIGFzIHJlcXVpcmVkLiBBIHBlZXIgcmVjZWl2aW5nIGEgcGFyYW1l dGVyIHJlcXVlc3QgYmVmb3JlIHRpbWVvdXQgcmVzZXRzIHRoZSB0aW1lb3V0IGdyZWF0ZXIg dGhhbiB0aGUgcG9sbCBpbnRlcnZhbCwgdGhlbiBzZW5kcyBhIHBhcmFtZXRlciByZXNwb25z ZS4gVGhlIG9yaWdpbmF0aW5nIHBlZXIgY29udGludWVzIHRoZSBkYW5jZSBieSBzZW5kaW5n IHJlcXVlc3QgbWVzc2FnZXMgYXMgcmVxdWlyZWQuIFRoZSByZXN1bHQgaXMgdGhhdCBvbmx5 IG9uZSBvZiB0aGUgdHdvIHBlZXJzIGV4ZWN1dGVzIHRoZSBkYW5jZS4NCg0KVGhlIGtleSBJ RCBpcyBjb2RlZCB0byBkaXN0aW5ndWlzaCBhZ3JlZWQga2V5cyBmcm9tIHRhYmxlIGtleXMu IFRoZSBjcnlwdG9ncmFwaGljIHN0cmVuZ3RoIGRlcGVuZHMgb24gdGhlIHNpemUgb2YgdGhl IGhhc2ggYW5kIHRoZSBoYXNoIGFsZ29yaXRobTsgb3RoZXJ3aXNlLCB0aGUgc3RyZW5ndGgg b2YgdGhlIGFncmVlZCBrZXkgYW5kIHRhYmxlIGtleSBhcmUgdGhlIHNhbWUuDQoNCldoaWxl IGl0IGlzIGNyeXB0b2dyYXBoaWNhbGx5IGhhcmQgdG8gbWFzcXVlcmFkZSBhcyBhIHZhbGlk IHBlZXIsIGNsaWVudCBvciBzZXJ2ZXIsIGEgY2xldmVyIG1pZGRsZW1hbiBjYW4gc2ltcGx5 IGNoYW5nZSBhIHBhY2tldCB0byBpbnRlbnRpb25hbGx5IGNhdXNlIGEgY3J5cHRvLU5BSyBh bmQgZXZlbnR1YWxseSBhIHByb3RvY29sIHJlc3RhcnQuIERvbmUgb2Z0ZW4gZW5vdWdoLCB0 aGUgcmVzdWx0IHJlcHJlc2VudHMgYSBkZW5pYWwgb2Ygc2VydmljZSBvcHBvcnR1bml0eS4N Cg0KOS42IERhbmNlIE1vdmVzDQoNClRoZSBwcm90b2NvbCBkYW5jZSBpcyBwcm90ZWN0ZWQg aW4gcGFydCBieSB0aGUgb24td2lyZSBwcm90b2NvbCBsYXllciBhbmQgYnkgdGhlIHNoYXJl ZCBoYXNoIGtleS4gVGhlIHBhcmFtZXRlciByZXF1ZXN0IGluY2x1ZGVzIHRoZSBzdWJqZWN0 IG5hbWUgb24gdGhlIGhvc3QgY2VydGlmaWNhdGU7IHRoZSBwYXJhbWV0ZXIgcmVzcG9uc2Ug aW5jbHVkZXMgdGhlIHN1YmplY3QgbmFtZSBvbiB0aGUgc2VydmVyIGNlcnRpZmljYXRlLiBU aGVzZSBuYW1lcyBjYW4gYmUgdmVyaWZpZWQgYnkgdGhlIGNsaWVudCBhc3NvY2lhdGlvbi4N Cg0KVGhlIGZpcnN0IGNlcnRpZmljYXRlIGV4Y2hhbmdlIHJldmVhbHMgdGhlIHNlcnZlciBj ZXJ0aWZpY2F0ZSB1c2VkIHRvIHZhbGlkYXRlIHRoZSBjb29raWUgZXhjaGFuZ2UuIEluIHN1 bW1hcnksIGEgaG9zdGlsZSBpbnRydWRlciBjYW5ub3QgdG9zcyBmYWtlIHZhbHVlcyB3aXRo IGVmZmVjdCBvbiB0aGUgc3RhdGUgb2YgdGhlIHJlY2lwaWVudC4gQXR0YWNrcyBvbiB0aGUg cGFyYW1ldGVyIGFuZCBjb29raWUgZXhjaGFuZ2VzIGFyZSBkZWZsZWN0ZWQgYnkga2V5IHpl cm8sIGJ1dCBhcmUgbWl0aWdhdGVkIGJ5IHRoZSBvbi13aXJlIGxheWVyOyBwYWNrZXRzIHdp dGggbG9vcGJhY2sgZXJyb3JzIGFyZSBpZ25vcmVkLiBUaHVzLCB0aGUgbW9zdCBsaWtlbHkg cmVzdWx0IG9mIGEgbWlkZGxlbWFuIGludmFzaW9uIGlzIGEgcmVzdGFydCwgcmF0aGVyIHRo YW4gYSBmYWxzZSBhZ3JlZW1lbnQuDQoNCkEgc2lnbmlmaWNhbnQgZGlzcnVwdGlvbiBpcyBs aWtlbHkgd2hlbiBhIG5ldyBwdWJsaWMvcHJpdmF0ZSBrZXkgYW5kIGNlcnRpZmljYXRlIGFy ZSBnZW5lcmF0ZWQgaW4gdGhlIG1pZGRsZSBvZiB0aGUgY2VydGlmaWNhdGUgdHJhaWwuIFRo aXMgcmVxdWlyZXMgcmVjb21wdXRpbmcgdGhlIG5ldyBjZXJ0aWZpY2F0ZSBzaWduYXR1cmUg aW4gdGhlIGltbWVkaWF0ZSB1cHN0cmVhbSBob3N0IGFuZCB0aGUgaW1tZWRpYXRlIGRvd25z dHJlYW0gaG9zdHMuDQoNCkluIGJyb2FkY2FzdCBtb2RlLCB0aGUgbW9zdCBwb3B1bGFyIGF0 dGFjayBpcyB0byByZXBlYXQgb2xkIHZhbGlkIG1lc3NhZ2VzLiBPcmRpbmFyaWx5LCB0aGVz ZSBhcmUgc3VwcHJlc3NlZCBieSB0aGUgdHJhbnNtaXQgdGltZXN0YW1wIGFzIGRlc2NyaWJl ZCBhYm92ZS4gSG93ZXZlciwgcHJvdG9jb2wgcmVzdGFydHMgYW5kIGxvc3QgcGFja2V0cyBt aWdodCByZXN1bHQgaW4gbWlzb3JkZXJlZCBtZXNzYWdlcy4gVGhlIGVubGlnaHRlbmVkIHJl c3BvbnNlIGlzIHRvIHJ1biBhIHRpbWVvdXQgdXBvbiByZWNlaXZpbmcgYSB2YWxpZCBtZXNz YWdlIGFuZCB0ZXJtaW5hdGUgaXQgdXBvbiByZWNlaXZpbmcgYSBtZXNzYWdlIHdpdGggYSBs YXRlciB0aW1lc3RhbXAuIE5vdGUgdGhhdCBhIHRlcnJvcmlzdCBjYW5ub3QgY29uc3RydWN0 IGEgdmFsaWQgbWVzc2FnZSwgYXMgaXQgY2Fubm90IGNvbnN0cnVjdCBhIHZhbGlkIHNpZ25h dHVyZS4NCg0KOS43IERpc3RyaWJ1dGVkIERlbmlhbCBvZiBTZXJ2aWNlIChERG9TKSBBdHRh Y2tzDQoNCk9mIHRoZSB0aHJlYXQgc2NlbmFyaW9zLCBhIEREb1MgYXR0YWNrIGlzIHRoZSBt b3N0IGRpc3J1cHRpdmUuIFRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gaW5jbHVkZXMg YSBtb3N0IHJlY2VudGx5IHVzZWQgKE1SVSkgbGlzdCB1c2VkIGJ5IHRoZSByYXRlIG1hbmFn ZW1lbnQgZnVuY3Rpb24uIEVhY2ggZW50cnkgaW5jbHVkZXMgdGhlIGNsaWVudCBJUCBhZGRy ZXNzLCBwcm9jZXNzIHRpbWUgb2YgYXJyaXZhbCBhbmQgcmVsYXRlZCBpbmZvcm1hdGlvbi4g VGhlIGxpc3QgaXMgb3JkZXJlZCBieSBpbmNyZWFzaW5nIHByb2Nlc3MgdGltZSBvZiBhcnJp dmFsIHdpdGggZHVwbGljYXRlIElQIGFkZHJlc3NlcyBzdXBwcmVzc2VkLiBUaGUgcHJvY2Vz cyB0aW1lIGlzIGltcGxlbWVudGVkIGJ5IGEgY291bnRlciB3aGljaCBpbmNyZW1lbnRzIG9u Y2UgcGVyIHNlY29uZCwgaW5kZXBlbmRlbnRseSBvZiB0aGUgTlRQIHN5c3RlbSBjbG9jay4N Cg0KRm9yIGVhY2ggYXJyaXZpbmcgcGFja2V0LCB0aGUgTVJVIGxpc3QgaXMgc2VhcmNoZWQg Zm9yIGFuIGVudHJ5IG1hdGNoaW5nIElQIGFkZHJlc3MuIElmIGZvdW5kLCB0aGUgaGVhZHdh eSBpcyBkZXRlcm1pbmVkIGFzIHRoZSB0aW1lIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbWF0 Y2hpbmcgZW50cnkgYW5kIHRoZSBhcnJpdmluZyBwYWNrZXQuICBJZiB0aGUgaGVhZHdheSBp cyBsZXNzIHRoYW4gdGhlIG1pbmltdW0sIHRoZSBwYWNrZXQgaXMgZGlzY2FyZGVkIHdpdGhv dXQgZnVydGhlciBwcm9jZXNzaW5nLiBJZiBub3QsIHRoZSBlbnRyeSBpcyB1bmxpbmtlZCBh bmQgdGhlIHBhY2tldCB0aW1lIGFuZCBJUCBhZGRyZXNzIGxpbmtlZCBmaXJzdCBvbiB0aGUg bGlzdC4NCg0KVGhlIHByb2Nlc3NpbmcgcmF0ZSBpcyB0aGUgdG90YWwgbnVtYmVyIG9mIGVu dHJpZXMgb24gdGhlIE1SVSBsaXN0IGRpdmlkZWQgYnkgdGhlIHRvdGFsIGVsYXBzZWQgcHJv Y2VzcyB0aW1lLiBUaGlzIGNhbiBiZSB1c2VkIGluIGEgc2NoZW1lIHRvIGRpc2NhcmQgcGFj a2V0cyBhcyB0aGUgcmF0ZSBpbmNyZWFzZXMgYWJvdmUgYSB0aHJlc2hvbGQuDQoNCkFuIG92 ZXJmbG93IG9mIHRoZSBNUlUgbGlzdCBpcyB3aGVuIHRoZSBudW1iZXIgb2YgZW50cmllcyBl eGNlZWRzIHRoZSBNUlUgbWF4aW11bSBzaXplLiBUaGlzIGNhbiBhbHNvIGJlIHVzZWQgaW4g YSBzY2hlbWUgdG8gZHJvcCBwYWNrZXRzLiBUaGVyZSBtaWdodCBiZSBvdGhlciBzY2hlbWVz IHVzaW5nIHRoZSBvdmVyZmxvdyBhcyB3ZWxsLg0KDQo5LjggQW1wbGlmaWNhdGlvbiBBdHRh Y2tzDQoNCkluIHRoZSBwcm90b2NvbCBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCwgYW4g YW1wbGlmaWNhdGlvbiBoYXphcmQgaXMgd2hlbiBhIHNtYWxsIHJlcXVlc3QgbWVzc2FnZSBy ZXN1bHRzIGluIGEgbGFyZ2UgcmVzcG9uc2UgbWVzc2FnZS4gIFRoaXMgaXMgYXZvaWRlZCBp biB0aGUgTlRTIHByb3Bvc2FsIGJ5IGluY2x1ZGluZyBhIGR1bW15IHBsYWNlaG9sZGVyIGlu IHRoZSByZXF1ZXN0LCBzbyB0aGF0IHRoZSByZXNwb25zZSBoYXMgdGhlIHNhbWUgbGVuZ3Ro IGFzIHRoZSByZXF1ZXN0LiAgVGhpcyBpcyBjb25zaWRlcmVkIGEgd2FzdGUgb2YgbmV0d29y ayByZXNvdXJjZXMgYW5kIGlzIHVubmVjZXNzYXJ5IGluIHRoZSBwcm90b2NvbCBwcm9wb3Nl ZCBoZXJlLg0KDQpXaXRoIHRoZSBwcm9wb3NlZCBleGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVu dCwgdGhlcmUgYXJlIG5vIGluc3RhbmNlcyBvZiBzaWduaWZpY2FudCBkaWZmZXJlbmNlcyBi ZXR3ZWVuIHRoZSBsZW5ndGhzIG9mIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzLCBl eGNlcHQgZm9yIHRoZSBjb29raWUgcmVzcG9uc2UgbWVzc2FnZSBpbiBjbGllbnQvc2VydmVy IG1vZGUsIGFzIGRlc2NyaWJlZCBwcmV2aW91c2x5LiAgVGhpcyBpcyBub3QgY29uc2lkZXJl ZCBhbiBhbXBsaWZpY2F0aW9uIGF0dGFjaywgc2luY2UgdGhlIGJvZ3VzIHJlY2lwaWVudCBj YW5ub3QgZnVydGhlciBhbXBsaWZ5IHRoYXQgbWVzc2FnZS4NCg0KOS45IERhdGEgTWluaW1p emF0aW9uDQoNCkEgaGF6YXJkIGhhcyBiZWVuIGlkZW50aWZpZWQgd2hlbiBhbiBpbnRlcmNl cHRvciBjYW4gbGVhcm4gc29tZXRoaW5nIGFib3V0IGNsaWVudCBsb2NhdGlvbiB1c2luZyBs ZWFrZWQgTlRQIGhlYWRlciB2YWx1ZXMuIEEgcHJvcG9zZWQgc29sdXRpb24gaXMgdG8gc2V0 IGFsbCBjbGllbnQgaGVhZGVyIGZpZWxkcyB0byB6ZXJvLCBleGNlcHQgdGhlIHRyYW5zbWl0 IHRpbWVzdGFtcCBmaWVsZCwgd2hpY2ggaXMgc2V0IHRvIGEgbm9uY2UuIEhvd2V2ZXIsIHRo aXMgcHJldmVudHMgY2FsY3VsYXRpb24gb2YgdGhlIGNsaWVudCBvZmZzZXQgYW5kIGRlbGF5 LCB3aGljaCBpcyB0aGUgaW50ZW50IG9mIHRoZSBwcm90b2NvbC4gVGhpcyBpcyBhbiB1bm5l Y2Vzc2FyeSBwcm9jZWR1cmUgYW5kIGlzIG5vdCByZWNvbW1lbmRlZC4gSWYgdGhpcyBwcm9j ZWR1cmUgaXMgaW5kZWVkIG5lY2Vzc2FyeSwgdGhlIGNsaWVudCBwYWNrZXQgY2FuIGJlIGZv cm1hdHRlZCBhcyBpbiBTTlRQIG9yIFVEUC9USU1FLg0KDQo5LjEwIENvbmZpZ3VyYXRpb24g U3VwcG9ydA0KDQpOb3RlIHRoYXQgdGhlIG9yaWdpbmFsIGxpYnJhcnkgcHJvZ3JhbSB1c2Vk IHRvIGdlbmVyYXRlIGtleXMgYW5kIGNlcnRpZmljYXRlIGFwcGxpY2F0aW9ucyBjb250aW51 ZXMgdG8gd29yayB3aXRoIHRoZSBwcm9wb3NlZCBzY2hlbWUuIEEgc2lnbmlmaWNhbnQgY2hh bGxlbmdlIGlzIHRvIG1pbmltaXplIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBjb25maWd1cmF0 aW9uIGVmZm9ydC4NCg0KMTAuIEhhY2tlciBPcHBvcnR1bml0aWVzDQoNCkNvbnNpZGVyIHdo ZW4gYSBzZXJ2ZXIgdXBkYXRlIGhhcyBwYXNzZWQgYWxsIGZvcm1zIG9mIGNyeXB0b2dyYXBo aWMgYW5kIHByb3RvY29sIGRlZmVuc2VzLiBBIGNyaXRpY2FsIHF1ZXN0aW9uIGlzIHdoZW4g dGhlIHNlcnZlciB0aW1lIGlzIGludGVudGlvbmFsbHkgZGlzcnVwdGVkIGluIG9yZGVyIHRv IGRlc3RhYmlsaXplIHRoZSBjbGllbnQgY2xvY2suIFRoZXJlIGFyZSBzZXZlcmFsIG11dHVh bGx5IGV4Y2x1c2l2ZSBoYWNrZXIgb3Bwb3J0dW5pdGllcyBkZXNjcmliZWQgYmVsb3cuDQoN CkluIGEgc3RvcCBhdHRhY2ssIHRoZSBzZXJ2ZXIgc2ltcGx5IHN0b3BzIG9wZXJhdGluZy4g VGhlIHJlc3VsdCBpcyB0aGF0IHRoZSBjbGllbnQgY2xvY2sgY29udGludWVzIGF0IGl0cyBp bnRyaW5zaWMgdGltZSBhbmQgZnJlcXVlbmN5LiBJZiB0aGUgZnJlcXVlbmN5IGlzIGZhciBm cm9tIG5vbWluYWwsIHRoZSBjbGllbnQgY2xvY2sgZXJyb3Igd2lsbCBncm93IHdpdGhvdXQg Ym91bmQuDQoNCkluIGEgcGFuaWMgYXR0YWNrLCB0aGUgc2VydmVyIGNsb2NrIG9mZnNldCBp cyBncmVhdGVyIHRoYW4gdGhlIHBhbmljIHRocmVzaG9sZCwgdXN1YWxseSA5MDAgc2Vjb25k cy4gSW4gdGhpcyBzY2VuYXJpbyB0aGUgY2xpZW50IGNsb2NrIGlzIHN0ZXBwZWQgdG8gc29t ZSBsYXJnZSBvZmZzZXQgZ3JlYXRlciB0aGFuIHRoZSBwYW5pYyB0aHJlc2hvbGQuIElmIGl0 IGlzIHRoZSBmaXJzdCB1cGRhdGUsIHRoZSBjbGllbnQgY2xvY2sgaXMgc3RlcHBlZCB0byB0 aGUgYXBwYXJlbnQgdGltZSBhbmQgb3BlcmF0aW9uIGNvbnRpbnVlcyB3aXRoIHRoaXMgdGlt ZS4gVGhpcyBpcyBvZnRlbiB0aGUgY2FzZSBhdCBjbGllbnQgc3RhcnR1cCB3aXRoIG5vIHJl YWwgdGltZSBjbG9jayBoYXJkd2FyZS4gSWYgaXQgaXMgbm90IHRoZSBmaXJzdCB1cGRhdGUs IHRoZSBjbGllbnQgc3RvcHMgdGhlIE5UUCBwcm9ncmFtIHdpdGggYSBsb2cgZW50cnkgYW5k IG9wZXJhdG9yIHdhcm5pbmcuIElmIHRoaXMgaGFwcGVucywgdGhlIGluZXhwZXJpZW5jZWQg b3BlcmF0b3Igc2ltcGx5IHJlc3RhcnRzIHRoZSBwcm9ncmFtIGFuZCB0aGUgZXZpbCBzdGVw IG9jY3VycyBhbnl3YXkuIFRoaXMgY2FuIGRlc3RhYmlsaXplIHRoZSBjbGllbnQgYXBwbGlj YXRpb25zIGluIG1hc3NpdmUgd2F5cy4NCg0KSW4gYSBzdGVwIGF0dGFjaywgdGhlIGNsaWVu dCBjbG9jayBpcyBzdGVwcGVkIGxlc3MgdGhhbiB0aGUgcGFuaWMgdGhyZXNob2xkLCBidXQg Z3JlYXRlciB0aGFuIHRoZSBzdGVwIHRocmVzaG9sZCwgdXN1YWxseSAxMjggbWlsbGlzZWNv bmRzLiBUaGUgc2VydmVyIGNvbnRpbnVlcyBpbiB0aGlzIHdheSBmb3IgdGhlIHN0ZXBvdXQg dGhyZXNob2xkLCB1c3VhbGx5IDkwMCBzZWNvbmRzLiBBZnRlciB0aGlzLCB0aGUgbmV4dCB1 cGRhdGUgd2lsbCBzdGVwIHRoZSBjbGllbnQgY2xvY2sgYnkgdGhlIHNlcnZlciB1cGRhdGUu IFRoZSBjbGV2ZXIgdGVycm9yaXN0IGNhbiByZXBlYXQgdGhpcyB3aXRoIGRpZmZlcmVudCBv ZmZzZXRzLCBjYXVzaW5nIHRoZSBjbGllbnQgY2xvY2sgdG8gb3NjaWxsYXRlIHdpbGRseS4N Cg0KSW4gYSBzd2lzaCBhdHRhY2ssIHRoZSBzZXJ2ZXIgdXNlcyBvZmZzZXRzIGxlc3MgdGhh biB0aGUgc3RlcCB0aHJlc2hvbGQgYnV0IGFkZHMgb3Igc3VidHJhY3RzIGluY3JlYXNpbmcg b2Zmc2V0cy4gVGhlIGNsb2NrIGV2ZW50dWFsbHkgcmVhY2hlcyBhbmQgaG9sZHMgYXQgdGhl IG1heGltdW0gZnJlcXVlbmN5LCBjdXJyZW50bHkgNTAwIHBhcnRzIHBlciBtaWxsaW9uLg0K DQoxMS4gSW1wbGVtZW50YXRpb24gU3VnZ2VzdGlvbnMNCg0KSnVkZ2luZyBmcm9tIGRldmVs b3BtZW50IGV4cGVyaWVuY2UsIHRpbmtlcmluZyB3aXRoIHByb3RvY29sIGRlc2lnbiBjYW4g YmUgdGVkaW91cy4gVGhlIGRhbmNlcyBpbnRlcmFjdCB3aXRoIHRoZSB0aW1lb3V0IGFuZCBy YXRlIG1hbmFnZW1lbnQgZnVuY3Rpb25zLCB3aGlsZSBleGNoYW5nZXMgbWF5IGVpdGhlciB0 aW1lb3V0IG9yIHJlc3VsdCBpbiBlcnJvci4NCg0KQ3VycmVudCBhbmQgdXNlZnVsIGZlYXR1 cmVzIG9mIHRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gbWF5IGJlIGxvc3QgaW4gYSBu ZXcgaW1wbGVtZW50YXRpb24uIFRoZSBlZmZlY3RpdmUgYXBwcm9hY2ggbWF5IGJlIHRvIGV2 aXNjZXJhdGUgdGhlIGN1cnJlbnQgQXV0b2tleSBwcm92aXNpb25zIGluIHRoZSByZWZlcmVu Y2UgaW1wbGVtZW50YXRpb24gYW5kIHJlcGxhY2Ugd2l0aCB0aGUgYWJvdmUgZGVzaWduLg0K DQpUaGlzIG1heSBub3QgYmUgYXMgZGlmZmljdWx0IGFzIGl0IHNlZW1zLiBUaGUgZmlyc3Qg c3RlcCBpcyB0byByZW1vdmUgYWxsIGV4dGVuc2lvbiBmaWVsZCByZWZlcmVuY2VzIHRvIGFz c29jaWF0aW9uIElELCB0aW1lc3RhbXBzIGFuZCBmaWxlc3RhbXBzLiBOb3RlIHRoYXQgdGhl IHByb2dyZXNzaW9uIG9mIGV4Y2hhbmdlcyBpcyBub3QgY2hhbmdlZC4gVGhlIG5leHQgc3Rl cCBpcyB0byBpbXBsZW1lbnQgdGhlIGNvb2tpZSBhbmQgREggYWdyZWVtZW50IGFsZ29yaXRo bXMgYXMgZGVzY3JpYmVkIGFib3ZlLiBUaGUgZmluYWwgc3RlcCBpcyB0byByZW1vdmUgYWxs IHJlZmVyZW5jZXMgdG8gdGhlIFNLRVkgc2NoZW1lIGFuZCByZXBsYWNlIHdpdGggdGhlIHNp Z25hdHVyZSBzY2hlbWUgYXMgZGVzY3JpYmVkLg0KDQoxMi4gQWx0ZXJuYXRpdmUgTW9kZWxz DQoNCkFzIGFuIGFzaWRlLCBBU04uMSBlbmNvZGluZyBvZiBleHRlbnNpb24gZmllbGRzIGlz IHByb2JhYmx5IG5vdCBhIGdvb2QgaWRlYS4gSG93ZXZlciwgQVNOLjEgaXMgYXBwcm9wcmlh dGUgZm9yIHBhcmFtZXRlciBkYXRhLiBBbGwgb3RoZXIgZXh0ZW5zaW9uIGZpZWxkcyB1c2Ug b25seSBvcGFxdWUgb2N0ZXQgc3RyaW5ncy4gRXZlbiBBU04uMSBlbmNvZGVkIGRhdGEsIHN1 Y2ggYXMgY2VydGlmaWNhdGVzLCBhcmUgdHJhbnNtaXR0ZWQgYXMgZmxhdCBvcGFxdWUgYml0 IHN0cmluZ3MuDQoNClRMUy9UQ1AsIERUTFMvVURQIG9yIGNvbWJpbmF0aW9ucyBvZiB0aGVz ZSBtaWdodCBiZSBhIGdvb2QgYWx0ZXJuYXRlIGFwcHJvYWNoLiBUaGUgbW90aXZhdGlvbiBm b3IgdGhpcyBhcHByb2FjaCBpcyB0byB1c2UgZXhpc3RpbmcgcHVibGljIHNlY3VyaXR5IHNj aGVtZXMgdG8gYXV0aGVudGljYXRlIE5UUCBwYWNrZXRzLiBUaGlzIGFwcHJvYWNoIHJlcXVp cmVzIGEgcHVibGljIHNvZnR3YXJlIHByb3RvY29sIHN0YWNrIG9yIGxpYnJhcnkuIEJlc2lk ZXMgZm9ybWluZyBhbiBhZGRpdGlvbmFsIHRhcmdldCBmb3IgaG9zdGlsZSBhdHRhY2ssIHRo ZSB0aW1lIGFuZCByZXNvdXJjZXMgcmVxdWlyZWQgbWF5IGJlIGJ1cmRlbnNvbWUgYW5kIHJl c3VsdCBpbiBzaWduaWZpY2FudCBsb3NzIG9mIHRpbWVrZWVwaW5nIGFjY3VyYWN5Lg0KDQpJ biB0aGUgY2FzZSBvZiBUTFMvVENQLCB0aGUgVENQIHByb3RvY29sIGRlc2lnbiBpcyBhdCBv ZGRzIHdpdGggdGhlIE5UUCBkYXRhZ3JhbSBzdHJ1Y3R1cmUgYW5kIHJhdGUgbWFuYWdlbWVu dCBwcmluY2lwbGVzLiBJbiBhZGRpdGlvbiwgVENQIHJlcXVpcmVzIGEgZm9ybWF0IGxheWVy IHRoYXQgaWRlbnRpZmllcyBwYWNrZXQgYm91bmRhcmllcy4NCg0KV2hpbGUgVENQIHByb3Zp ZGVzIHJlbGlhYmxlIGRlbGl2ZXJ5LCByZXRyYW5zbWlzc2lvbnMgcmVuZGVyIE5UUCB0aW1l c3RhbXBzIGVzc2VudGlhbGx5IHVzZWxlc3MuIFRoZSBOVFAgcGFja2V0IHJhdGUgbGltaXQg bW9kZWwgaXMgYXQgb2RkcyB3aXRoIHRoZSBUQ1AgYXJjaGl0ZWN0dXJlLCB3aGVyZSB0aGUg cmVzb3VyY2VzIHRvIGNvbnNlcnZlIGFyZSBidWZmZXJzIGFuZCBkYXRhIGZsb3cgbWFuYWdl bWVudC4NCg0KVGhlIFRDUCBtb2RlbCByZXF1aXJlcyBib3RoIHNlcnZlciBhbmQgY2xpZW50 IHRvIG1haW50YWluIHByb3RvY29sIHN0YXRlLCB3aGljaCBpcyBub3QgcHJhY3RpY2FsIGlu IGEgc3RhdGVsZXNzIHNlcnZlciBhcmNoaXRlY3R1cmUuIEl0IGFsc28gcmVxdWlyZXMgY29w eWluZyBOVFAgcGFja2V0cyB0byBpbnRlcm5hbCBidWZmZXJzIGFuZCB0aGVuIGNvcHlpbmcg ZGF0YSBmcm9tIHRoZXNlIGJ1ZmZlcnMgdG8gTlRQIG1lc3NhZ2VzLiBUaGUgb3ZlcmhlYWQg aW4gdGhlc2UgYWN0aW9ucyB3b3VsZCBvdmVyd2hlbG0gYSBwcm9jZXNzb3IgZmFjZWQgd2l0 aCBhIHN3YXJtIG9mIDMwMDAgTlRQIHBhY2tldHMgcGVyIHNlY29uZC4gRmluYWxseSwgdGhl IFRMUy9UQ1AgcHJvdG9jb2wgb3ZlcmhlYWQgcmVxdWlyZXMgdXAgdG8gc2V2ZW4gY29udHJv bCBwYWNrZXRzIGluIGFkZGl0aW9uIHRvIHRoZSBkYW5jZSBwYWNrZXRzLCB3aGlsZSBvYmV5 aW5nIHRoZSByYXRlIGNvbnN0cmFpbnRzLiBUaGUgaW5ldml0YWJsZSBjb25jbHVzaW9uIGlz IHRoYXQgYW55IHNlY3VyaXR5IG1vZGVsIGJhc2VkIG9uIFRDUCBpcyBpbmFwcHJvcHJpYXRl IGZvciBkaXJlY3QgdXNlIGJ5IE5UUC4NCg0KRFRMUy9VRFAgYXQgZmlyc3QgZ2xhbmNlIHNl ZW1zIGEgbXVjaCBiZXR0ZXIgc2VjdXJpdHkgcHJvdG9jb2wgZm9yIE5UUCB0aGFuIFRMUy9U Q1AgZHVlIHRvIGl0cyBpbnRyaW5zaWMgc3RydWN0dXJlIGJhc2VkIG9uIGRhdGFncmFtIHBy aW5jaXBsZXMuIEhvd2V2ZXIsIGluIHRoaXMgcHJvdG9jb2wsIHRoZSBiYXNpYyBOVFAgaGVh ZGVyIGFuZCBleHRlbnNpb24gZmllbGRzIGFyZSBlbWJlZGRlZCBpbiB0aGUgRFRMUy9VRFAg cmVjb3JkIHByb3RvY29sLCB3aGljaCByZXF1aXJlcyBjb3B5aW5nLCBhcyBpbiBUTFMvVENQ LiBUaGlzIHJlc3VsdHMgaW4gY29uc2lkZXJhYmxlIG92ZXJoZWFkIGFuZCBsb3NzIG9mIHRp bWVzdGFtcCBhY2N1cmFjeS4NCg0KVGhlIGhhbmRzaGFrZSBwcm90b2NvbCBpcyBub3Qgd2Vs bCBwcm90ZWN0ZWQsIGJ1dCB0aGUga2V5IHplcm8gc2NoZW1lIGNvdWxkIHJlc29sdmUgdGhp cyBwcm9ibGVtLiBIb3dldmVyLCB0aGUgcmVjb3JkIHByb3RvY29sIGNvdWxkIGJlIGF2b2lk ZWQgaWYgdGhlIEkvTyBidWZmZXIgY29udGFpbnMgdGhlIGNvbXBsZXRlIE5UUCBwYWNrZXQg aGVhZGVyLCBQRFVzLCBhbmQgTUFDLiBUaGlzIGlzIGFuIGV4YW1wbGUgb2YgdGhlICJ0b3Vj aCBvbmx5IG9uY2UiIHByaW5jaXBsZSwgd2hpY2ggaXMgYWRvcHRlZCBpbiB0aGUgYWJvdmUg cHJvcG9zYWwgYXMgd2VsbC4NCg0KQSBzaG93c3RvcHBlciBwcm9ibGVtIGlzIHRoYXQgRFRM Uy9VRFAgaXMgbGltaXRlZCB0byBjbGllbnQvc2VydmVyIG1vZGUuIFRoaXMgZG9jdW1lbnQg aXMgY2FyZWZ1bGx5IGNyYWZ0ZWQgdG8gaW5jbHVkZSBzeW1tZXRyaWMgbW9kZS4gSW4gcHJp bmNpcGxlLCB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgbW9kZXMgaXMgaW4g dGhlIGFncmVlbWVudCBwaGFzZSBvZiB0aGUgY29va2llIGV4Y2hhbmdlLiBUaGUgbmVlZCB0 byBhc3NlbWJsZSBEVExTIGhlYWRlcnMgYW5kIHRyYWlsZXJzIGFuZCBOVFAgcGFja2V0cyBp biByZWNvcmRzIG1heSByZXF1aXJlIGNvcHlpbmcgZGF0YSBpbiBidWZmZXJzLCByZXN1bHRp bmcgaW4gZnVydGhlciBvdmVyaGVhZC4gVGhlIERUTFMvVURQIGhhbmRzaGFrZSBwcm90b2Nv bCBjb3VsZCBiZSB1c2VkIHdpdGhvdXQgdGhlIHJlY29yZCBsYXllci4NCg0KRm9yIHRoZSBi ZXN0IGFjY3VyYWN5LCB0aGUgb24td2lyZSB0aW1lc3RhbXBzIHNob3VsZCBiZSBpbXBsZW1l bnRlZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgZW5kIG9mIHBhY2tldCBoYXJkd2Fy ZSBpbnRlcnJ1cHQuIFRoZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gZG9lcyB0aGlzIGJ5 IGFuIGludHJpY2F0ZSBzY2hlbWUgaW52b2x2aW5nIHRoZSBVbml4IGludGVycnVwdCBxdWV1 ZSBhbmQgcmVjb3JkaW5nIHRoZSB0aW1lc3RhbXAgaW4gdGhlIGlucHV0IHBhY2tldCBidWZm ZXIuIEluIHRoZSBEVExTL1VEUCBtb2RlbCwgdGhlIGJ1ZmZlciBpcyB0aGVuIHBhc3NlZCB0 byB0aGUgRFRMUy9VRFAgcmVjb3JkIHByb3RvY29sLCB3aGljaCBtaWdodCBub3QgcHJlc2Vy dmUgdGhlIHRpbWVzdGFtcC4gVGhpcyB3b3VsZCBiZSBwb3NzaWJsZSBvbmx5IHdpdGggY29u c2lkZXJhYmxlIG1vZGlmaWNhdGlvbnMgdG8gdGhlIERUTFMvVURQIHB1YmxpYyBzb2Z0d2Fy ZSBkaXN0cmlidXRpb24uDQoNClRvIGNvbnRpbnVlIHN1cHBvcnQgZm9yIHRoZSBub24tYXV0 aGVudGljYXRlZCBwcm90b2NvbCBhbmQgdGhlIGF1dGhlbnRpY2F0ZWQga2V5cyBmaWxlIG1v ZGVsLCB0aGUgTlRQIHBvcnQgbXVzdCBiZSAxMjMgYXMgcmVxdWlyZWQgZm9yIGhpc3Rvcmlj IG9wZXJhdGlvbnMuIFRoZXJlZm9yZSwgYSBuZXcgRFRMUy9VRFAgc2VjdXJpdHkgcHJvdG9j b2wgbXVzdCBiZSBzdXBwb3J0ZWQgb24gYSBkaWZmZXJlbnQgcG9ydC4NCg0KVGhlIHVzZSBv ZiBEVExTIG9uIGEgcG9ydCBvdGhlciB0aGFuIDEyMyBjYW4gc3VwcG9ydCBzZWdtZW50YXRp b24gYW5kIHJlYXNzZW1ibHkgZm9yIHRoZSBoYW5kc2hha2UgcHJvdG9jb2wgYnV0IHJlc3Vs dCBpbiB1c2VsZXNzIHRpbWVzdGFtcHMuIFRoZSByZWFsIGtpbGxlciBpbiBhIERUTFMvVURQ IGRlc2lnbiBpcyB3aGF0IHRvIGRvIGFib3V0IGZyYWdtZW50YXRpb24gYW5kIHJlYXNzZW1i bHkuIEFwcGFyZW50bHksIHRoZSBjdXJyZW50IHNlY3VyaXR5IGluZnJhc3RydWN0dXJlIHJl cXVpcmVzIGNlcnRpZmljYXRlcyBvZiBvdmVyIDUwMDAgb2N0ZXRzLCB3aGljaCByZXF1aXJl IG11bHRpcGxlIGZyYWdtZW50cyBub3QgZ3JlYXRlciB0aGFuIHRoZSAxNTAwLW9jdGV0IE1U VS4gRFRMUy9VRFAgc29sdmVzIHRoaXMgcHJvYmxlbSBieSBmcmFnbWVudGF0aW9uIGFuZCBy ZWFzc2VtYmx5IGJ1dCByZXN1bHRzIGluIHVuYWNjZXB0YWJsZSBsb3NzIG9mIHRpbWVrZWVw aW5nIGFjY3VyYWN5LiBUaGUgbW9zdCBlZmZlY3RpdmUgc29sdXRpb24gaXMgdG8gcmVxdWly ZSBjZXJ0aWZpY2F0ZXMgdG8gYmUgbGVzcyB0aGFuIHRoZSBNVFUgb2YgMTUwMCBvY3RldHMu IEl0IGlzIG5vdCBjbGVhciB3aHkgc3VjaCBsYXJnZSBwYWNrZXRzIGFyZSByZXF1aXJlZCBi dXQgdGhlIHNpbXBsZSBvYnNlcnZhdGlvbiBpcyB0aGF0IGNlcnRpZmljYXRlcyBmb3IgTlRQ IHNlY3VyaXR5IG5lZWQgbm90IGJlIGFzIHJvYnVzdCBhcyBuZWVkZWQgZm9yIHdlYiBicm93 c2luZy4NCg0KMTMuIFBhcnRpbmcgU2hvdHMNCg0KV2l0aCByZXNwZWN0IHRvIHRoZSBOVFAg bW9kZWwgaW4gUkZDNTkwNSwgdGhlIHByb3Bvc2VkIHByb3RvY29sIGluIHRoZSBOVFMgYW5k IE5UUCBkb2N1bWVudHMgc2VlbXMgYXQgb2Rkcy4gVGhlIE5UUyBzY2hlbWUgbWFrZXMgbm8g ZGlzdGluY3Rpb24gYmV0d2VlbiBjbGllbnQvc2VydmVyIGFuZCBzeW1tZXRyaWMgbW9kZXMs IGFzIHN5bW1ldHJpYyBtb2RlIGRvZXMgaW5kZWVkIGhhdmUgc3RhdGUuIFRoZSBwcm9wb3Nl ZCBOVFMgYnJvYWRjYXN0IHNjaGVtZSByZXF1aXJlcyBhIHR3by13YXkgbWVzc2FnZSBwYXRo LCB3aGljaCBpcyBub3QgYSByZXF1aXJlbWVudCBpbiB0aGUgTlRQIG1vZGVsLiBXaGlsZSB0 aGUgcHJvcG9zZWQgTlRTIHNjaGVtZSBjb3VsZCBiZSBhIGNvbmZpZ3VyYXRpb24gb3B0aW9u LCB0aGUgcHJvcG9zZWQgc2NoZW1lIGluIHRoaXMgZG9jdW1lbnQgaXMgYSBuZWNlc3NpdHkg Zm9yIHRoZSBvbmUtd2F5IGNvbmZpZ3VyYXRpb24uDQoNCk9uIHRoZSBvdGhlciBoYW5kLCB0 aGUgcHJvcG9zZWQgTlRTIHNjaGVtZSBzZWVtcyB3aG9sbHkgYXBwcm9wcmlhdGUgZm9yIGFu IGFwcGxpY2F0aW9uIHN1Y2ggYXMgdGhlIElQIFRJTUUgb3IgU05UUCBwcm90b2NvbCwgd2hl cmUgdGhlcmUgaXMgbm8gb24td2lyZSBwcm90b2NvbCBsYXllci4gV2l0aCBOVFAsIHRoaXMg bGF5ZXIgYXZvaWRzIHRoZSBuZWVkIGZvciBleHBsaWNpdCBub25jZSBhbmQgc2Vzc2lvbiBr ZXlzLg0KDQpUaGVyZSBhcmUgc29tZSB3YXJ0cyBpbiB0aGUgcmVmZXJlbmNlIGltcGxlbWVu dGF0aW9uIGFuZCBwcm9wb3NlZCBwdWJsaWMga2V5IHNjaGVtZXMuIFRoZXJlIG1pZ2h0IGJl IG90aGVyIHdheXMgdG8gdmFsaWRhdGUgdGhlIGNlcnRpZmljYXRlIHRyYWlsIG90aGVyIHRo YW4gcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KQXMgaW4gYWxsIGNyeXB0b2dyYXBo aWMgc2NoZW1lcywgcHJvdmlzaW9ucyBtdXN0IGJlIG1hZGUgdG8gcmVmcmVzaCB0aGUga2V5 IG1hdGVyaWFsLiBBcyBzdWdnZXN0ZWQgYWJvdmUsIHRoZSBzZWNyZXQga2V5IG9mIHRoZSBz ZXJ2ZXIgc2hvdWxkIGJlIHJlZnJlc2hlZCBhYm91dCBvbmNlIHBlciBkYXkuIEZvciBtb3Jl IGRpc3J1cHRpb24gZHVlIHRvIGNlcnRpZmljYXRlIHVwZGF0ZXMsIHRoZSBwcmVzZW50IGRl c2lnbiBkb2VzIHRoaXMgYnkgc2h1dHRpbmcgZG93biBhbmQgdGhlbiByZXN0YXJ0aW5nIGFs bCBhc3NvY2lhdGlvbnMgb25jZSBwZXIgd2Vlay4gTW9yZSBzb3BoaXN0aWNhdGVkIHNjaGVt ZXMgbWlnaHQgYmUgZGV2aXNlZC4NCg0KUmFyZSBjb2xsaXNpb25zIHdvdWxkIGJlIGV4cGVj dGVkIGluIHN5bW1ldHJpYyBtb2RlLiBUaGlzIHdvdWxkIGhhcHBlbiB3aGVuIGJvdGggcGVl cnMgc3RhcnQgdGhlIHByb3RvY29sIGF0IHRoZSBzYW1lIHRpbWUuIFRoaXMgY2FuIGJlIGF2 b2lkZWQgdXNpbmcgYSByYW5kb20gZGVsYXkgYXQgYXNzb2NpYXRpb24gc3RhcnR1cCwgYXMg ZGVzY3JpYmVkIHByZXZpb3VzbHkgaW4gdGhpcyBkb2N1bWVudC4NCg0KVGhlIG1vc3Qgb2Jq ZWN0aW9uYWJsZSBpc3N1ZSBhYm91dCB0aGUgcHJvcG9zZWQgTlRTIGZvciBOVFAgZG9jdW1l bnQgaXMgaXRzIGFzdG9uaXNoaW5nIGNvbXBsZXhpdHkuIFRoZXJlIGlzIG5vIG5lZWQgZm9y IHR3byBrZXlzIGluIGNsaWVudC9zZXJ2ZXIgbW9kZS4gVGhlcmUgaXMgbm8gbmVlZCB0byBl eHBvcnQga2V5cywgdW5sZXNzIHRoZSBpbnRlbnQgaXMgdG8gcHJvdmlkZSByZWNvdmVyeSBv ZiBrZXlzIGZvciBmb3JlbnNpYyBwdXJwb3Nlcy4NCg0KVGhlIERUTFMvVURQIGhhbmRzaGFr ZSBleHBvc2VzIGFuIGFzdG9uaXNoaW5nIHBhbm9wbHkgb2YgYXBwYXJlbnRseSB1c2VsZXNz IG9wdGlvbnMuIFByb3Zpc2lvbnMgdG8gcmVuZWdvdGlhdGUga2V5cyBpcyBzdXBlcmZsdW91 cywgc2luY2UgdGhlIHByb3RvY29sIGNhbiBzaW1wbHkgYmUgcmVzdGFydGVkLg0KDQpUaGUg cHJvcG9zZWQgc3ltbWV0cmljIGtleSBoYW5kc2hha2UgaW4gdGhlIE5UUyBkb2N1bWVudCBp cyBhd2t3YXJkIGF0IGJlc3QuIEl0IGNhbiByZXN1bHQgaW4gdW5zdGFibGUgb3BlcmF0aW9u IGFuZCBleGNlc3NpdmUgaGFuZHNoYWtlIHRpbWVzLg0K --------------D5942FFE712D6E4ED125EDB3-- From nobody Thu Sep 14 04:57:47 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 ADCC7132D8E for ; Thu, 14 Sep 2017 04:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=libertysys.com.au 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 psR4JSLKI_cO for ; Thu, 14 Sep 2017 04:57:45 -0700 (PDT) Received: from mail.libertysys.com.au (ppp178-79.static.internode.on.net [150.101.178.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A27126BF0 for ; Thu, 14 Sep 2017 04:57:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.libertysys.com.au (Postfix) with ESMTP id 9C0C392256 for ; Thu, 14 Sep 2017 21:57:40 +1000 (AEST) X-Virus-Scanned: Debian amavisd-new at mail2.gear.dyndns.org Received: from mail.libertysys.com.au ([127.0.0.1]) by localhost (mail.gear.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB6NuyUGEN8a for ; Thu, 14 Sep 2017 21:57:30 +1000 (AEST) Received: from [172.22.64.102] (eber-home.gear.dyndns.org [172.22.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.libertysys.com.au (Postfix) with ESMTPSA id C82349224C for ; Thu, 14 Sep 2017 21:57:30 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libertysys.com.au; s=2016; t=1505390250; bh=xqqXUrUjU8qfRfbjOLDWeFQH9xDFwxuvqpfhXaF+734=; h=To:From:Subject:Date; b=Z3wNcLV7MY9+sW73jYAgQvkB/RyrVmk/KEGj6ZvygMPVZqmNl0avFlR62L2BV0PEv 0mVNIOfyb3+0WsKONg9bGIkpKXz53VNUwq1C7QeZwH6XxEap1MWFPdoElvs3CY7+Wp 5N0Bya3O+a4yy26OTkBpcSbJbypdm7Z/iUzFI6Pk= To: ntp@ietf.org From: Paul Gear Message-ID: <8f66743e-dcf5-b75a-d752-3f6bf525166c@libertysys.com.au> Date: Thu, 14 Sep 2017 21:57:35 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-AU Archived-At: Subject: [Ntp] Feedback on drafts from AusNOG conference 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: Thu, 14 Sep 2017 11:57:47 -0000 Hi all, Thanks to sponsorship by NTF, I recently attended AusNOG 2017 to give a presentation about NTP - slides are available at http://www.ausnog.net/events/ausnog-2017/programme. I hope I have adequately represented the state of affairs with the RFC drafts. There were two interesting pieces of technical feedback which I wanted to pass on. Firstly, during the time for questions at the end of my talk, Geoff Huston from APNIC questioned the viability of DTLS. He claimed that a) one of the DNS working groups (DNS privacy, I think) had found that there were no viable implementations of DTLS for their purposes when they surveyed the field recently, and b) there are issues with packet fragmentation in some switch/router chipsets which could cause problems with the use of UDP for DTLS. I asked him about this in more detail later, and he indicated that the fragmentation problem was an IPv6-only issue, whereby he found that a certain significant percentage of DNS clients on the Internet cannot receive fragmented replies to requests due to the fact that some routers and/or switches drop fragmented IPv6 packets. I found both of Geoff's claims very unusual, so I went looking for DTLS libraries and found that both OpenSSL and GnuTLS claim to support DTLS. I downloaded python DTLS (https://pypi.python.org/pypi/Dtls), which claims to use OpenSSL internally, and started writing some code to create a DTLS tunnel with it. I haven't managed to get NTP to sync over it, but I did manage to get it to complete a certificate exchange with a 931-byte self-signed certificate. The certificate exchange took place over several packets, due to the fact that either OpenSSL or python DTLS split up the certificate into 256-byte chunks to send over the connection. So I think my fears about packet size under NTS peer/control modes and Geoff's about fragmentation are probably unfounded (although I didn't test IPv6 yet, so that is still up for grabs). The second issue was raised by Steinthor Bjarnason of Arbor Networks, a DDoS mitigation vendor. He raised the point that if their DDoS mitigation engine sees an NTP packet with NTS extensions in it without seeing an NTS KE TCP connection prior to that, they could use that as a heuristic for deciding that the UDP traffic was illegitimate. During our discussion I realised that this wouldn't be a valid heuristic, because NTS is specifically built with client mobility in mind, and it's completely plausible for a single client - say, a dual-SIM mobile handset - to do its preliminary NTS key exhange via TCP over its wifi interface, then send an NTP packet with NTS Extension Fields via UDP over one cellular connection, and the next NTP packet with NTS Extension Fields via UDP over its second cellular connection. This would be completely allowable (even natural) behaviour for an NTS client. I pointed out that even if the NTS standard mandated using the same IP address for both the TCP and UDP exchanges, it wouldn't be practical to enforce, since that would require the server holding additional state, which is specifically not desired by NTS. I don't think this is a problem for NTS, merely an observation that whilst it aims not to contribute to DDoS attacks, it will also not assist DDoS mitigation technologies in distinguishing legitimate from illegitimate traffic. Consensus at the conference seemed to be that DDoS mitigation vendors are in for an increasingly difficult time over the next few years as bandwidth at the edge increases much more quickly than bandwidth at the core. Regards, Paul From nobody Thu Sep 14 12:36:13 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 EA91E132D8C for ; Thu, 14 Sep 2017 12:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=tglassey@earthlink.net header.d=earthlink.net 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 GR-jPdSFeeK2 for ; Thu, 14 Sep 2017 12:36:11 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1911241F3 for ; Thu, 14 Sep 2017 12:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1505417770; bh=HTQBPGfZDbSwoB0xt3tT+EQ4TN+NHYmTzZw7 KFYmb2s=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=LjfzAZUshlSx4pNywaA8CRcaSgyrSU97x k9gMC37j2OUADrJa3o8DwbLQlhobLAZt7xHCCnzP3hUZkr13ZcYq2izauCfOrKvYUCz qJel3ccC1C1+l2T1/uRWXCus13Ruz1k9lfu7Xpwu7cThu40U0YS12+gJq34/J1uRmBz ecEnX1iVLtLKTZuZQH3FP1fhxRhIaMMHJR4/0oLpeMaxFiRjdRakc6HH1Kd0oubDD9X L0LvHKNYQED9TLF3mX4i4CkG8qfyf63DsHDbD5l4L6hQgZUhKUqzxZHgl5GC9R7QV0u p+7SBl581ggoCM57tcI/47lqq/o+NBolLPkhM/3Xg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=FJggPjQhc0YoDOAc097d5aGk8/wnP/31YQhBaAAUfsz2rGasMaGj7yMGx0Y0Kf1IaB32xsUYvTNAZtO7H51DjkCjHqi6RCGY05CdB8St5OhhajaVVuE3FvZB8C7uFPlahzrkMxtB/rQKRqFn72mTw1cKDqxluhx1AXPYM4tSzPAF/vrtJHFx1XnTPByB5dEbQXp8tBj27mvejavrxyarPqabgsGeY+SqGgql6Gl6XA3g8rW/M1GTiStW02+JR9If2RSED9q6Qgpg5JDWeondFZk3k5KHZaiN5iRj1UmA/kkMWrV/0SdN7+b6R34+KyrOwUhiQ1o92bm5vlHXxvQHgg==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [73.189.24.178] (helo=[192.168.0.55]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1dsZvl-0004Zz-F3 for ntp@ietf.org; Thu, 14 Sep 2017 15:36:09 -0400 To: ntp@ietf.org References: <4d249b7a-3f61-3183-749a-d05832fed0ec@nwtime.org> From: TGlassey-Earthlink Message-ID: <576cdddd-c466-b8ff-bede-be3c35e74a6a@earthlink.net> Date: Thu, 14 Sep 2017 12:36:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4d249b7a-3f61-3183-749a-d05832fed0ec@nwtime.org> Content-Type: multipart/alternative; boundary="------------62718429C6F44039E8789792" Content-Language: en-US X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79719be12098a7deddc3da7a6dd0b8798e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 73.189.24.178 Archived-At: Subject: Re: [Ntp] Dave's latest Autokey document 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: Thu, 14 Sep 2017 19:36:13 -0000 This is a multi-part message in MIME format. --------------62718429C6F44039E8789792 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Great work folks, but there is an issue which has been brewing since the ruling from the USDC against setting the settlements for US6370629 and US6393126 aside. Instead of setting them aside - the ruling from the court had an unintended judicial consequence - it judicially perfected the plain text reading of the documents which is orders of magnitude worse than just setting them aside. It means everyone using the IP must apply California Law to it. That is the free-use restriction. If you dont want to apply California Law - you pay for the release. Microsemi has no legal standing to sell that release - they dont own the use of the IP outside of the ConfidentialCourier product. That means everyone in the timekeeping world MUST COMPLY WITH THE RULING NOW. SORRY... What I am concerned about now is how we apply USDC 14-CV-03629/WHA's ruling to all NTP and secured PTP operations across all platforms. I am sure this is the last thing anyone wants to deal with, but under the ruling - all timestamping is controlled exclusively by California Law and IETF itself as a named co-defendant is tied to the unintended consequences of the ruling therein. The two settlements by the way - tie this and every other timestamping use model tied to any network event including remote-time-delivery to that patent and its silly settlement which today controls all timesetting as well as time controlled events. //TSG On 09/13/2017 07:12 PM, Harlan Stenn wrote: > > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --------------62718429C6F44039E8789792 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Great work folks, but there is an issue which has been brewing since the ruling from the USDC against setting the settlements for US6370629 and US6393126 aside. Instead of setting them aside - the ruling from the court had an unintended judicial consequence - it judicially perfected the plain text reading of the documents which is orders of magnitude worse than just setting them aside. It means everyone using the IP must apply California Law to it. That is the free-use restriction. If you dont want to apply California Law - you pay for the release. Microsemi has no legal standing to sell that release - they dont own the use of the IP outside of the ConfidentialCourier product.

That means everyone in the timekeeping world MUST COMPLY WITH THE RULING NOW.  SORRY...

What I am concerned about now is how we apply USDC 14-CV-03629/WHA's ruling to all NTP and secured PTP operations across all platforms. I am sure this is the last thing anyone wants to deal with, but under the ruling - all timestamping is controlled exclusively by California Law and IETF itself as a named co-defendant is tied to the unintended consequences of the ruling therein. The two settlements by the way - tie this and every other timestamping use model tied to any network event including remote-time-delivery to that patent and its silly settlement which today controls all timesetting as well as time controlled events.

//TSG

On 09/13/2017 07:12 PM, Harlan Stenn wrote:

      

      

      

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


    

    

  


--------------62718429C6F44039E8789792--


From nobody Fri Sep 15 05:20:00 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 823DB133207 for ; Fri, 15 Sep 2017 05:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 uQM0EA-bKB2L for ; Fri, 15 Sep 2017 05:19:57 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7DA133200 for ; Fri, 15 Sep 2017 05:19:57 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8FCHh8Q014054; Fri, 15 Sep 2017 13:19:53 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=dvn5VVVMe+sQY2xaN+w5Ztf+7PnSMaQka319HFItuVo=; b=Yn+L5PTCi+RAyJgfmhTfChOJRJLyY+ST8hzwcYTPiSlqW/xe10CuRr06p0ItQ2Zmnpy7 9R278Tb8zX3i3IlaDufKCseAfN5/wDgHgEHjxD+JnHPLI9+9XSw64UvSJ4hiH7Cupl3A WTuQGX/9sqZVOv3OY+qs1EIx6xbPMBDFaPO/8psgffWnvUzOsAbJPnDp+8wCxo8dsGQF x72QsQiuDZ475BDRW73EURLfJZ80/hJ9irtty6cO4m8QegLOBxhhpwJguBsBHI2fhJ8w xqbRjiXDrz++toDoPWni5wfzgTi6ke7eEKVwsgzrzePbxYtRIFRAdiCDWraTYsdKeZM/ 7w== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2cxfy8c77d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Sep 2017 13:19:53 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8FC5viV004428; Fri, 15 Sep 2017 08:19:52 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2cwwe3nbpt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 15 Sep 2017 08:19:52 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 07:19:51 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 15 Sep 2017 07:19:51 -0500
From: "Salz, Rich" 
To: TGlassey-Earthlink , "ntp@ietf.org" 
Thread-Topic: [Ntp] Dave's latest Autokey document
Thread-Index: AQHTLP74ln4dRWOCj0+0Mhy3Cj5etqK1G0AAgADVYAA=
Date: Fri, 15 Sep 2017 12:19:51 +0000
Message-ID: <6D52E181-E7D6-4575-96E6-62528EA58058@akamai.com>
References: <4d249b7a-3f61-3183-749a-d05832fed0ec@nwtime.org> <576cdddd-c466-b8ff-bede-be3c35e74a6a@earthlink.net>
In-Reply-To: <576cdddd-c466-b8ff-bede-be3c35e74a6a@earthlink.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.40.113]
Content-Type: multipart/alternative; boundary="_000_6D52E181E7D6457596E662528EA58058akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-15_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709150177
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-15_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709150179
Archived-At: 
Subject: Re: [Ntp] Dave's latest Autokey document
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: Fri, 15 Sep 2017 12:19:59 -0000

--_000_6D52E181E7D6457596E662528EA58058akamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXMgdGhlcmUgYW55dGhpbmcgZm9yIHVzIHRvIGRvIG90aGVyIHRoYW4gZm9yIHNvbWVvbmUgdG8g
d3JpdGUgYW4gSVBSIGRpc2Nsb3N1cmU/DQoNCg0K

--_000_6D52E181E7D6457596E662528EA58058akamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <252BB8690D386847907520E404AF02CF@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls
ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3Vy
aWVyO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lu
cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn
ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu
IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg
bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6Q2FsaWJyaSI+SXMgdGhlcmUgYW55dGhpbmcgZm9yIHVzIHRvIGRvIG90aGVyIHRoYW4g
Zm9yIHNvbWVvbmUgdG8gd3JpdGUgYW4gSVBSIGRpc2Nsb3N1cmU/PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh
bGlicmk7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_6D52E181E7D6457596E662528EA58058akamaicom_--


From nobody Fri Sep 15 08:24:28 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 94AD8132FA6 for ; Fri, 15 Sep 2017 08:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level: 
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org
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 pCYbIsaCz2SV for ; Fri, 15 Sep 2017 08:24:25 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0088.outbound.protection.outlook.com [104.47.38.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8238132F65 for ; Fri, 15 Sep 2017 08:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cA0nO6a0nZVh3UA/pgKoT7O3WZDlYBs4oUedfxXWPeU=; b=wHIcRX9+M5p65WrIuohtNDfHps5wBqmQRJDu2oM3v/vwZQyXUs4yu/s//fA0527NT9yhLrqpKaSyCMMYZvMGL4yVBRzxNYl3x0jEVz6f+M7vYxscP2qIHW0k4n5gSXu5WDN/PwdXPFULkvc1EX62r46MEA7TSLwBsXITVTjJrjc=
Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB3557.namprd06.prod.outlook.com (10.171.249.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Fri, 15 Sep 2017 15:24:22 +0000
Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0056.010; Fri, 15 Sep 2017 15:24:22 +0000
From: Karen O'Donoghue 
To: Rich Salz 
CC: TGlassey-Earthlink , "ntp@ietf.org" 
Thread-Topic: [Ntp] Dave's latest Autokey document
Thread-Index: AQHTLP734rbHw95vKk2SSNWAm3iiw6K0x24AgAEYb4CAADONgA==
Date: Fri, 15 Sep 2017 15:24:22 +0000
Message-ID: <45B48BEE-2E17-4E9E-94EC-EEDB811E79F9@isoc.org>
References: <4d249b7a-3f61-3183-749a-d05832fed0ec@nwtime.org> <576cdddd-c466-b8ff-bede-be3c35e74a6a@earthlink.net> <6D52E181-E7D6-4575-96E6-62528EA58058@akamai.com>
In-Reply-To: <6D52E181-E7D6-4575-96E6-62528EA58058@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; 
x-originating-ip: [24.245.108.20]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR06MB3557; 6:UAil2PwvCMeXYBLG5YyoyU60DFDUjekkgqNBj6ERTiJUzhAtoI7WEt/dssFbrgei2t3AkISx8RNKJdTUQ2fNEWQroixTvX7MJtB5sHwucYrc01Gdito4bkh8Xu4K/6Gk40587rr+pusd5TmQW7pGop1JQKnO/H7xM4nyYW1A9XwAWArq3ZXWJCq9PprlFcXdaJ1gac7HrPI7fLijVH2OigsEhF4lPgGQP2zFxibUE9fn08idbp20aQEA69ULGaFlN35fZp+tHO5No5FJAmzmKoggEJ2TQGRqVfbDHLAnzrRuiwFhsr2Mzg2v5e1oakC8qV1kY5okungvwnX6dL/01g==; 5:cMT2HUkKu99AMNP7b/6reLc/GPoYxWdna51ISbGKHPfu/8ftASFki75ckinSDm9vrMk6JSQhjsUiK+mFRE3aHTYNtzhDONSzvmIhpvacxhHBSMo5fI6lAkKAInMk0+RKgfsMAQnWOGTwp4dB4nfehw==; 24:f4ExEip98CrUc65bUOHy+PfjJ5RcW3Ae6O3kA7ktrpRR+JShY1tHdejJ/dzD9WTp7ADGUghmM3KxA1wgT5VCzBAVyOOM9j1omoow2n/Q7CY=; 7:e/00R+zQe1d28nvdVOUOuLpm2at1RepS7timZNcbwqqbzf3BI2SDekgjCmiaTZZf6rza3s7d4ZxQiXrKe2e+p8p3JehPl4V+uixn4EhLSOQkxwamndos78RFj188/0up6pAoD+GBXjFOTy2C1piaoAeQIAmHbl5+V4vGa4HBAcajvWP/NbjPhWyMfHUpazUrK7cvMJLNxl454O1FII3CnPSbdST5Ony5/FkRvLIJ/4Y=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 5e409fc4-5812-47a6-256e-08d4fc4dd76c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB3557; 
x-ms-traffictypediagnostic: CY4PR06MB3557:
x-exchange-antispam-report-test: UriScan:;
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)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB3557; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB3557; 
x-forefront-prvs: 0431F981D8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(376002)(346002)(377454003)(189002)(24454002)(199003)(66066001)(54896002)(54906002)(6512007)(478600001)(236005)(97736004)(316002)(110136004)(53546010)(6246003)(82746002)(606006)(54356999)(6506006)(101416001)(77096006)(6436002)(53936002)(36756003)(6306002)(5660300001)(2900100001)(189998001)(50986999)(105586002)(76176999)(33656002)(3280700002)(8676002)(6486002)(8936002)(25786009)(83716003)(106356001)(966005)(68736007)(2950100002)(4326008)(3846002)(81166006)(99286003)(6916009)(102836003)(3660700001)(14454004)(2906002)(229853002)(86362001)(8666007)(81156014)(7736002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB3557; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_45B48BEE2E174E9E94ECEEDB811E79F9isocorg_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2017 15:24:22.0609 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB3557
Archived-At: 
Subject: Re: [Ntp] Dave's latest Autokey document
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: Fri, 15 Sep 2017 15:24:27 -0000

--_000_45B48BEE2E174E9E94ECEEDB811E79F9isocorg_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Rm9sa3MsDQoNClRoZXJlIGlzIGEgbG9uZyBoaXN0b3J5IG9mIGxlZ2FsIGFjdGlvbiBiZXR3ZWVu
IFRvZGQgR2xhc3NleSwgTWljcm9zZW1pLCBhbmQgdGhlIElFVEYuIEkgaGF2ZSBmb3J3YXJkZWQg
VG9kZOKAmXMgZW1haWwgdG8gSUVURiBsZWFkZXJzaGlwIGZvciBndWlkYW5jZS4gQXQgdGhpcyB0
aW1lLCB0aGVyZSBpcyBub3RoaW5nIGZvciB1cyB0byByZXNwb25kIHRvLg0KDQpLYXJlbg0KDQpP
biBTZXAgMTUsIDIwMTcsIGF0IDg6MTkgQU0sIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb208
bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZToNCg0KSXMgdGhlcmUgYW55dGhpbmcgZm9y
IHVzIHRvIGRvIG90aGVyIHRoYW4gZm9yIHNvbWVvbmUgdG8gd3JpdGUgYW4gSVBSIGRpc2Nsb3N1
cmU/DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cm50cCBtYWlsaW5nIGxpc3QNCm50cEBpZXRmLm9yZzxtYWlsdG86bnRwQGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHANCg0K

--_000_45B48BEE2E174E9E94ECEEDB811E79F9isocorg_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRm9sa3MsDQo8ZGl2IGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSBpcyBhIGxvbmcgaGlz
dG9yeSBvZiBsZWdhbCBhY3Rpb24gYmV0d2VlbiBUb2RkIEdsYXNzZXksIE1pY3Jvc2VtaSwgYW5k
IHRoZSBJRVRGLiBJIGhhdmUgZm9yd2FyZGVkIFRvZGTigJlzIGVtYWlsIHRvIElFVEYgbGVhZGVy
c2hpcCBmb3IgZ3VpZGFuY2UuIEF0IHRoaXMgdGltZSwgdGhlcmUgaXMgbm90aGluZyBmb3IgdXMg
dG8gcmVzcG9uZCB0by4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkthcmVuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh
c3M9IiI+T24gU2VwIDE1LCAyMDE3LCBhdCA4OjE5IEFNLCBTYWx6LCBSaWNoICZsdDs8YSBocmVm
PSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSIgY2xhc3M9IiI+cnNhbHpAYWthbWFpLmNvbTwvYT4m
Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N
CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBX
b3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91
bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv
bWFuJzsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p
bHk6IENhbGlicmk7IiBjbGFzcz0iIj5JcyB0aGVyZSBhbnl0aGluZyBmb3IgdXMgdG8gZG8gb3Ro
ZXIgdGhhbiBmb3Igc29tZW9uZSB0byB3cml0ZSBhbiBJUFIgZGlzY2xvc3VyZT88bzpwIGNsYXNz
PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw
MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBj
bGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsi
IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L2Rpdj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250
LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i
c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGZs
b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0i
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl
ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdi
KDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp
OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5udHAN
CiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm
b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0
ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0i
Ij4NCjxhIGhyZWY9Im1haWx0bzpudHBAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0
ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z
aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1
dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw
eDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIi
Pm50cEBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt
c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0K
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAiIHN0eWxl
PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6
IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv
OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1
NSwgMjU1KTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bnRwPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFj
a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_45B48BEE2E174E9E94ECEEDB811E79F9isocorg_--


From nobody Fri Sep 15 16:35: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 80E321321C9 for ; Fri, 15 Sep 2017 16:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level: 
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=tglassey@earthlink.net header.d=earthlink.net
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 8IEU_98BYf7D for ; Fri, 15 Sep 2017 16:35:54 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE27129A89 for ; Fri, 15 Sep 2017 16:35:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1505518554; bh=chKSTSaJcRzByKucGY2gdfIAO3fH0gfYtoUq cbGT2f4=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=lwN2EVMR9FEPyMcBp3DUrkg6fd+QwG0nm uuEWCWKJ5O0oXALQR9J45rzK3rPcEdwrEYpk0ewPvLdGUhBfH4oPi5hBniPkIFj4XcY 9YQZYJj+z1hXSPGvFrq2j8WPNbzdA1PWRqxt2dm9ILBk8KljBGhRImMmqcNQIC0GuPK iwkqt9fpxhEb3ruA8zrfnoqxFADodDUcDcOfUiSvxbGFSWfkyimOHsAaiDjosXVfrli wzMaVcQA36NRtEfLoqa/yFytyQtwOvan6pjKORJeDjmiEeWzG86xZoqZVL2bVBhcVIB sj976SzhUn0TgSN7dQZoKj1xqIxbIRnSQXcBeiOhA==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=osp/Jb3LVA3VxBzxVhd6rMkoVknPexHF9SsDw1BOKUq07Bzmy2fA3Tq4OGWjKoBTos0Oce8W2VCky2ca/1anURtr/FPlelS5glei8XwL6PoRBP3THngNdGcKi33w9lq0sCRa8RGyY5ydeituewYutewqoBYngKHLsaaU8UszT7TS9xPtqZokPg53s7U93T9X3wRnsdEO87jCoT/6SIsO0dza77QPQ5hP5rZ+F6Lq5JWxxrLeIl221jYvtASvPTXjlJb7k/j8lGh9Nyl3wTNuqCwzW11TOtBHdM156QrVyeKXF8WXeiYi6aPGq6kdYxfSxm/XOueuw2qCmyPi0LtFRg==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [73.189.24.178] (helo=[192.168.0.55]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1dt09I-000Fgb-OE; Fri, 15 Sep 2017 19:35:52 -0400
To: "Salz, Rich" , "ntp@ietf.org" 
References: <4d249b7a-3f61-3183-749a-d05832fed0ec@nwtime.org> <576cdddd-c466-b8ff-bede-be3c35e74a6a@earthlink.net> <6D52E181-E7D6-4575-96E6-62528EA58058@akamai.com>
From: TGlassey-Earthlink 
Message-ID: <188b9092-9645-176f-81f8-0ea7dfe8c8a1@earthlink.net>
Date: Fri, 15 Sep 2017 16:35:51 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <6D52E181-E7D6-4575-96E6-62528EA58058@akamai.com>
Content-Type: multipart/alternative; boundary="------------5D5C32537ABAD79C1D989079"
Content-Language: en-US
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79901de1f6ebb5b16df98fcb7bce87575e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 73.189.24.178
Archived-At: 
Subject: Re: [Ntp] Dave's latest Autokey document
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: Fri, 15 Sep 2017 23:35:56 -0000

This is a multi-part message in MIME format.
--------------5D5C32537ABAD79C1D989079
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Rich - I think that an IPR is appropriate but the reality folks is the 
ruling came down from the USDC - 14-CV-03629/WHA  and it effects the NTP 
EULA radically. That requires the Licensing to be radically changed. IT 
IS NOT NEGOTIABLE - THE COURT RULING IS DONE AND IETF WAS RIGHT THERE AS 
DIRECT PARTY TO THE RULING. No product providing a set of services which 
use US6370629 may operate outside the laws of the State of California. 
Its right in Alsup's ruling affirming that clause in the Settlement and 
its enforcement standing. (Apple, Microsoft, Google, etc) objected - in 
fact Apple pushed to stop all review of the Settlements in all forms as 
did Microsoft and others.

The judge supported their demands and he refused to set that settlement 
aside. He then  dismissed the case with prejudice meaning no one of 
those or any other party really can challenge the requirements in 
Section 8 of the settlement. This had an UNINTENDED CONSEQUENCE which 
today forces the application of the State of California Laws to all 
timestamping from US6370629 or its 269 derivatives or US6393126 or its 
105 derivatives.

Because of the ruling, this changed the licensing you may provide to any 
third party to being controlled by Section 8 of the US6370629 Settlement 
and specifically section 8.4, 8.3, and 8.1 - the California Law mandate. 
As such the IETF License doesn't work. So you need to pull NTP from IETF 
because of the ruling and the Appellate Cases effects (9th 14-17574 and 
DC Cir 15-01326).

Sorry, but no... we are not waiving the mandatory application of the 
California Law clause to everything however vendors can buy a release 
for it. Have your lawyers contact us and we can set up a convo and do a 
deal.

That said, my apologies but honestly, we are the real victims here...

//TSG

On 09/15/2017 05:19 AM, Salz, Rich wrote:
>
> Is there anything for us to do other than for someone to write an IPR 
> disclosure?
>
> **
>


--------------5D5C32537ABAD79C1D989079
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Rich - I think that
        an IPR is appropriate but the reality folks is the ruling came
        down from the USDC - 14-CV-03629/WHA  and it effects the NTP
        EULA radically. That requires the Licensing to be radically
        changed. IT IS NOT NEGOTIABLE - THE COURT RULING IS DONE AND
        IETF WAS RIGHT THERE AS DIRECT PARTY TO THE RULING. No product
        providing a set of services which use US6370629 may operate
        outside the laws of the State of California. Its right in
        Alsup's ruling affirming that clause in the Settlement and its
        enforcement standing. (Apple, Microsoft, Google, etc) objected -
        in fact Apple pushed to stop all review of the Settlements in
        all forms as did Microsoft and others. 

      

    
The judge supported
        their demands and he refused to set that settlement aside. He
        then  dismissed the case with prejudice meaning no one of those
        or any other party really can challenge the requirements in
        Section 8 of the settlement. This had an UNINTENDED CONSEQUENCE
        which today forces the application of the State of California
        Laws to all timestamping from US6370629 or its 269 derivatives
        or US6393126 or its 105 derivatives. 

      

    
Because of the
        ruling, this changed the licensing you may provide to any third
        party to being controlled by Section 8 of the US6370629
        Settlement and specifically section 8.4, 8.3, and 8.1 - the
        California Law mandate. As such the IETF License doesn't work.
        So you need to pull NTP from IETF because of the ruling and the
        Appellate Cases effects (9th 14-17574 and DC Cir 15-01326). 

      

    Sorry, but no... we are
      not waiving the mandatory application of the California Law clause
      to everything however vendors can buy a release for it. Have your
      lawyers contact us and we can set up a convo and do a deal. 

      

      That said, my apologies but honestly, we are the real victims
      here... 

    

    //TSG

    

    
On 09/15/2017 05:19 AM, Salz, Rich
      wrote:

    

    

      
      
      
      
      
      

        
Is there
            anything for us to do other than for someone to write an IPR
            disclosure?

        
 

        
 

      

    

    

  


--------------5D5C32537ABAD79C1D989079--


From nobody Fri Sep 15 16:43: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 574F41321A7 for ; Fri, 15 Sep 2017 16:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level: 
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=tglassey@earthlink.net header.d=earthlink.net
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 MN8FTSjjvXHb for ; Fri, 15 Sep 2017 16:43:20 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742E4129A89 for ; Fri, 15 Sep 2017 16:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1505519000; bh=D/dnUtyXnk4MWDGLHCcp4xeQTm+XOA72qkSl QIXChIo=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=lQTAKz0qAkta5jdGttArjARr8fvizSG5l 7naLZnp9z6aoa5NHsQQ4SdFHTJEz8lZbPCUgpWB+iK9dpcN5v/iRp5yAaQ1jokQFNkC YDPuW2o442QUrcu1Sj4k2Wi21hIvhUne+n61qEr3FXY2UxEGCnx6XqKJsCRB2jub+9y uVt9e3I+Ds7DZP43GzbXD5HgdK0tUEw1Ii+F61kM1sgWCOJg6x1eI1Cic37ECOzcTSO r1MF2s8eIVfg0i6HK3mvbbHDyeDD+amwrhliYUBCllfxKFVX6r91xFCv3rksxKByKdA ddX4OtZMu+scS/I+wAq8ThjYcma/aVHkSpwiQPM6Q==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=BUI8d1KmaP1PWfSNkfnZz8Xo6+rhWF4yTkGrH6b1ur5r+E/M9V88/MCQidbmjVmSJXOBKRB+rbSTVMTlmtCl/vOcy/thqOAEf36ZYdTt39NQ6YFfunAhXNRlSlLx8Ib+YEZ4uuuPDBGqdHJUI4QSBgZijL5dxwAHw6xd5aoKuGXjgT23e9q0UvE0Gq3DdULmEocnu5/SKpSOxIqzO4ZVdIWnIsgAAhn6bnRvumpCxYuygflHzsxSBBwB84cLipCPQhD+KoLXHOWj06kt43XNmAKAPF948xZ0T1GblysQNCuljF4QqTBVkXqGU7LptCKHfMaQwXw4NoK9hsT+bbfgCQ==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [73.189.24.178] (helo=[192.168.0.55]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1dt0GV-000Anl-7I for ntp@ietf.org; Fri, 15 Sep 2017 19:43:19 -0400
To: ntp@ietf.org
References: <4d249b7a-3f61-3183-749a-d05832fed0ec@nwtime.org> <576cdddd-c466-b8ff-bede-be3c35e74a6a@earthlink.net> <6D52E181-E7D6-4575-96E6-62528EA58058@akamai.com> <45B48BEE-2E17-4E9E-94EC-EEDB811E79F9@isoc.org>
From: TGlassey-Earthlink 
Message-ID: <69f93354-aaad-6f40-ff4a-41408a87d8e3@earthlink.net>
Date: Fri, 15 Sep 2017 16:43:18 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <45B48BEE-2E17-4E9E-94EC-EEDB811E79F9@isoc.org>
Content-Type: multipart/alternative; boundary="------------E8570B88A04A86F6DE1B8AAF"
Content-Language: en-US
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec797cd5021d28d13a673fd81f3b9652c321350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 73.189.24.178
Archived-At: 
Subject: Re: [Ntp] Dave's latest Autokey document
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: Fri, 15 Sep 2017 23:43:22 -0000

This is a multi-part message in MIME format.
--------------E8570B88A04A86F6DE1B8AAF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Karen - the USDC ruling is in. Sorry - you are bound to the ruling just 
like I am... 14-CV-03629/wha controls you as well as everyone using NTP 
when certain authentication and security methods are included in those 
NTP transactions today.  It also requires that the Licensing be properly 
changed to support the ruling.
And then there are the frauds - AU54015/99, CA2287596, EU0997808A3, 
BR9904979A, ZA9906799, JP2000-163379, KO2000-0035093 which make using 
the NTP Timestamping facilitation a crime in those nations.

Sorry - the ruling is in.

//tsg

On 09/15/2017 08:24 AM, Karen O'Donoghue wrote:
> Folks,
>
> There is a long history of legal action between Todd Glassey, 
> Microsemi, and the IETF. I have forwarded Todd’s email to IETF 
> leadership for guidance. At this time, there is nothing for us to 
> respond to.
>
> Karen
>
>> On Sep 15, 2017, at 8:19 AM, Salz, Rich > > wrote:
>>
>> Is there anything for us to do other than for someone to write an IPR 
>> disclosure?
>> **
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ntp
>
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp


--------------E8570B88A04A86F6DE1B8AAF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Karen - the USDC ruling is in. Sorry - you are bound to the ruling
    just like I am... 14-CV-03629/wha controls you as well as everyone
    using NTP when certain authentication and security methods are
    included in those NTP transactions today.  It also requires that the
    Licensing be properly changed to support the ruling. 

    And then there are the frauds - AU54015/99, CA2287596, EU0997808A3,
    BR9904979A, ZA9906799, JP2000-163379, KO2000-0035093 which make
    using the NTP Timestamping facilitation a crime in those nations. 

    

    Sorry - the ruling is in. 

    

    //tsg

    

    
On 09/15/2017 08:24 AM, Karen
      O'Donoghue wrote:

    

    

      
      Folks,
      


      

      
There is a long history of legal action between Todd
        Glassey, Microsemi, and the IETF. I have forwarded Todd’s email
        to IETF leadership for guidance. At this time, there is nothing
        for us to respond to. 

      


      

      
Karen

      


        

          

            
On Sep 15, 2017, at 8:19 AM, Salz, Rich <rsalz@akamai.com> wrote:

            

            

              

                

                  Is there anything for us to do other than
                    for someone to write an IPR disclosure?

                

                   

                

                   

              

              _______________________________________________

              ntp mailing list

              ntp@ietf.org

              https://www.ietf.org/mailman/listinfo/ntp

            

          

        

        

      

      

      

      

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


    

    

  


--------------E8570B88A04A86F6DE1B8AAF--


From nobody Sat Sep 16 01:08:44 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 2D6EB13308C for ; Sat, 16 Sep 2017 01:08:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 6TxQE8zgtn0x for ; Sat, 16 Sep 2017 01:08:40 -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 449C5129B7A for ; Sat, 16 Sep 2017 01:08:40 -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 D829AB835; Sat, 16 Sep 2017 08:08:39 +0000 (UTC)
From: Harlan Stenn 
To: ntp@ietf.org
References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org>
Message-ID: <2f478606-6e59-fc80-4568-9016ae3cbdb5@nwtime.org>
Date: Sat, 16 Sep 2017 01:08:39 -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: <47b5b4e3-41c9-6779-4a96-b11650483499@nwtime.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
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: Sat, 16 Sep 2017 08:08:42 -0000

I'm reading the latest version from Daniel, dated 26 June but last
modified on 1 Sept (or so).

Some of the points I raised in my email of 27 August 2017 22:05:02 -0700
have been addressed.  Most have not.

I think I have (re)captured all of my points below.

While folks have asked for technical comments, it may be that clearing
up at least some of the more significant editorial comments will result
in a better proposal.

TL;DR: I oppose advancing the document as it currently stands as a
standards-track document, for the reasons below.

This document might be fine for EXPERIMENTAL status, which I think we
should do if we aren't planning to be certain that it works correctly
before advancing this document.  It might also be OK for this document
to be INFORMATIONAL.

Once we have confidence that this specification is robust, I'd be happy
to see it as a STANDARDS track document.

** Technical comments:

1.1. Objectives
- Identity:  Just a comment.  If we don't know what time it is, how can
we trust an X.509 PKI?  This is somewhat addressed by 9.2., and I'd
appreciate clarification and assurances from additional sources.

- Authentication: The authentication functionality of NTS is no
different from the existing symmetric key encryption already provided by
RFC5905, correct?

- Confidentiality: Is the only expected current use of this facility the
cookie supply sent from the server to the client?

- Replay prevention: Again, the core NTP specification already has
replay prevention.  The proposed language is misleading, implying that
without NTS there is no replay protection.  If the existing core
protection against replay is inadequate, please describe the problem(s).
 You could also say "NTS offers another, additional layer of replay
prevention beyond what NTP already provides."

- Request-response consistency: Again, the core NTP protocol already has
request-response consistency checks, where useful.  The proposed
language is misleading, implying that without NTS there is no
request-response consistency checking.  If the existing checks for
request-response consistency is inadequate, please describe the
problem(s).  You could also say "NTS offers another, additional layer of
request-response consistency checks beyond what NTP already provides."

- Unlinkability:  The new language is an improvement.  Even so, - the
stated threat seems extraordinarily unlikely to be possible if more than
several networks are involved.  Even if such a threat was possible and
used, if the client/server model for NTS is to use NTP packets with NTS
extension fields, an outside observer can still see that there is a
client sending requests to a set of servers that some other client has
used before.  How is that traffic not "linkable"? This "feature" seems
to be a red-herring.

- Non-amplification: Does this mean that the NTS proposal is attempting
to enforce non-amplification of NTP packets even if NTS is not being
used?  Is "never responding to a request with a packet larger than the
request packet" inviolate?  This sounds like micro-management to me, and
can easily be thwarted by bad guys who just send a bigger packet from a
forged source address to a server.  As I wrote before: The core problem
is DDoS.  Amplification is a secondary problem.  Sure, the avoidance of
amplification is a useful interim step.  But the target protocol isn't
the place to solve the DDoS problem.  DDoS is basically an "overcommit"
problem.  BCP38, anyone?

- Scalability: The way this is phrased is confusing.  If this goal is
specific to NTS, then it should say so.  Given the subsequent
discussions about C2S, S2C, etc., it also seems disingenuous.  Aside
from these things, it seems to be another red-herring.  More detail below.

- DTLS-encapsulated NTPv4: No mention is made of the fact that this
method will increase timing jitter, and degrade the quality of
timekeeping.  This is especially troublesome given that peer mode is
mostly used for groups of lower-stratum servers offering time to many
clients.  I believe this degradation MUST be disclosed.

1.2. Protocol Overview

- NTS EFs for NTPv4: Saying NTS EFs are suitable for client/server but
not for other modes seems incorrect to me.  If NTS-KE had the option to
exchange keys for both sides, then NTS EFs would be suitable for
symmetric mode, and I submit, offer better time quality than the
proposed symmetric mode over DTLS.

The premise that "all server state must be avoided" should be
re-examined.  We already need to maintain some server state to watch for
attacks, and no analysis has been provided to show what the tradeoffs
are between maintaining some server state compared with the
computational costs of regenerating key validation information from the
incoming client cookie.

~It is intended that DTLS will be used for symmetric and control modes,
and NTS-KE+NTS-EFs will handle client/server.~  See 2 paragraphs above,
for a request to understand why NTS-KE+NTS-EFs cannot be used for
symmetric mode.  Also, there are control mode situations where UDP is
suboptimal, and a more functional communication would be desired.

Last paragraph: "(This constant refreshing of cookies is necessary in
order to achieve NTS's unlinkability goal.)" - please describe this
better, as it still seems to me that there is plenty of information
available in the base packet, including the destination host and several
other fields, that would be useful for determining linkability.  See
"Unlinkability" comment above.

4. The DTLS-encapsulated NTPv4 protocol

I believe this section should discuss the degradation that will(?) occur
when transporting NTPv4 packets over a DTLS connection.  This includes:

- current inability to use interleave mode, because current DTLS
  implementations don't support SO_TIMESTAMPING, for the transmit
  timestamp
- potential for UDP packet fragmentation
- likely need to copy the NTP packet into DTLS packets
- any issues around grabbing the receive timestamp

There might be others - this is the list off the top of my head.

4.1 says "Implementations may find that they have multiple, redundant
DTLS sessions open with the same peer."  Shouldn't the protocol take
steps to prevent this from happening?  I need to read this document
again to understand this situation, as it seems to me that it should not
happen in general, and if it did happen, there should be specific,
listed cases, and then specific actions should be taken to "clean up."
I'm not sure about these things, but I am curious about them and wonder
if they should be better described.

6.2. Packet structure overview

- "Possibly, some additional extensions which are neither encrypted nor
authenticated.  >These are discarded by the receiver.<"  The part about
discarding EFs after the NTS packet IS wrong - it's over-reach.

- The purpose of the cookie extension field is to enable the server
  to offload storage of session state onto the client.

As above, this MAY be useful.  It may not always be useful, and an
analysis should be done to understand the time/space tradeoffs between
using a cookie and having to regenerate data based on the cookie, and
saving some state on the server.  This may not be significant, but we
should have a proper engineering basis for the decision.

- The purpose of the unique-identifier extension field is to protect
  the client from replay attacks.

The core protocol ALREADY has replay prevention protection.  Please show
how that protection is defective or inadequate.  Or make the editorial
change to say the purpose of the UIEF is to provide ADDITIONAL
protection from replay attacks.

"Possibly, some additional extension fields which are neither
 encrypted nor authenticated.  These are discarded by the receiver."

No.  Overreach.  The NTS proposal must not dictate policy outside of its
scope.  Lose "These are discarded bu the receiver."

We do not want to burn a separate EF type for each NTS EF "directive",
6.[3456].

6.3: "Historically, NTP's origin timestamp field has played
   both these roles, but for cryptographic purposes this is suboptimal
   because it is only 64 bits long and, depending on implementation
   details, most of those bits may be predictable."

Please substantiate this claim.  It smells of herring and/or FUD.

6.4: NTS Cookie EF:  If the NTS-KE is bi-directional, then NTS EFs could
also be used for symmetric mode associations.

6.5: NTS Cookie Placeholder: Ditto re 6.4 above.  Furthermore, I don't
believe that the claim about amplification is significant.  It is also
unclear that timekeeping accuracy is universally negatively affected if
the size of the client and server responses differ.  LAN and WAN?  Wired
and wireless?  Overloaded channels v. "not overloaded" channels?

6.6: NTS AEE EF: See 6.4 above.

Where is the MAC?

Is it encrypted?

NTP has traditionally allowed for several layers of protection and
checking.  If the base packet checks fail, we do no more processing of
the packet.  If the base packet checks succeed, then if the packet is
authenticated we are able to make sure the packet passes the
authentication MAC checks.  It is *only* after these checks have passed
that we do deep packet processing.

I still do not see where NTS keeps its MAC, and how we can do the above
validations before doing deep packet processing.

If deep packet processing is required to do NTS packet authentication,
then NTS is creating a larger DOS vector for an NTP implementation.

What other EFs are expected to be encrypted in the AEAD section?  What
should be done if encryped EFs are found to be invalid?

Are you using the "authentication tag" described in the Ciphertext
section  of 6.6 to mean the MAC?  If so, this would seem to violate the
expected behavior.

6.7 Protocol details

"In general, however, the server MUST discard any unauthenticated
 extension fields and process the packet as though they were not
 present.  Servers MAY implement exceptions to this requirement for
 particular extension fields if their specification explicitly
 provides for such."

No, overreach.  NTS has no business making these statements or
requirements.  They are properly handled elsewhere.

Under what circumstances will a client send multiple cookie placeholder EFs?

"If the server is unable to validate, ... KoD ...": This is
overloading/mis-using KoD.  What is wrong with the crypto-NAK for this
purpose?  More bluntly, since this point was not addressed from my
earlier message on the topic, this is a job for crypto-NAK, and we
should not misuse/overload KoD for this.

"Upon receiving an NTS NAK, the client MUST verify that the Unique
 Identifier matches that of an outstanding request.  If this check
 fails, the packet MUST be discarded without further processing."

I'm not sure about this.  I recall there are reasons that we might want
to update some variables even when we are going to discard a packet.  It
won't take much to verify this, but we should do it before specifying
this language.

8. IANA considerations:

Why are we requesting a dedicated TCP port for NTS-KE instead of using
TCP/123?  Please describe the pros/cons of each approach somewhere.

See above.  NTS should use exactly 1 Extension Field Type, and the UI,
Cookie, Cookie Placeholder, and AE directives should be EF Codes.

9.1 DDoS amplification:
"NTS-related extension fields included in server responses will be
 the same size as the NTS-related extension fields sent by the client."

First, how difficult will it be for a bad guy to send a large packet to
a server, thereby REQUIRING that the server respond with an
identically-sized response to the (spoofed) target?

I propose:

  NTS-related extension fields included in server responses SHOULD
  be no larger than the packets sent by the putative client.

9.3 Usage of NTP Pools:

"pool organizers will need to act as certificate authorities, regularly
 monitor the behavior of servers to which certificates have been issued,
 and promptly revoke the certificate of any server found to be serving
 incorrect time."

Inappropriate language/assumption of authority.  How about:

 Pool organizers will SHOULD act as (or in collaboration with their)
 certificate authorities, regularly monitor the behavior of servers to
 which pool certificates have been issued, and promptly revoke the
 certificate of any server found to be serving incorrect time.

10.1 Unlinkability.  I mention this here only because I'm reading the
document from start to finish.  I've discussed this before, and I still
think it's a red-herring.  It seems to me the most linkable bit of
information in a client request is the destination address.  If this
isn't the case I think we'd all benefit from a proper study of the issues.

Similarly, the claim about linkability due to mode 4 (server) responses
seems highly suspicious, because one would expect that most *all*
responses from a given server would have repeatable REFID, reftime, and
stratum.

10.2. Confidentiality.  Please.  What client-confidential information
exists in a normal NTP header that is not able to be adequately
protected right now?  When using SNTP queries with minimal data fields
one already gets all of the protections described in
ntp-data-minimization.  Limiting the specification of remediation of
this issue to the data minimization draft is ... suboptimal (I'm sure
you can think of other words to use).  The point about "Future extension
fields could hypothetically contain sensitive information" seems
implausible.  Have any such possibilities >that are appropriate for an
NTP Extension Field< packet even been considered?  But assuming there is
a way to tell NTS to send this information encrypted, that would mean
that the peer-mode DTLS
connection would have to provide encryption, and the client/server NTS
EF would have to provide an API, which has not been described here, to
contain this encrypted information.

** Editorial comments:

Please use consistent punctuation. (eg, missing period at the end of
1.1. Objectives: Identity).

1.2. Protocol Overview

"These various modes have different and contradictory requirement for
security and performance."  This is a naive observation, and is not
true.  We *always* care about performance and security.  Different modes
simply use different equations for deciding how to achieve the
performance and security goals they require.

"In order to simultaneously serve these *conflicting* requirements..."
Again, the requirements are not conflicting, they're just different,
based on the use-case.

"... NTS is structured as a suite of three protocols:"  It should be
noted that other methods to accomplish these goals are possible, and
that what is subsequently described is *one* way that is expected to
satisfy the requirements.

"The "NTS Extension Fields for NTPv4" are ..." is better now, thanks.
The phrase "cryptographically securing NTPv4" is another way to say
"offers tamper protection via MAC", right?  "Cryptographically securing"
seems too general to me, as it could easily be misconstrued to mean
"encrypted".

5. The NTS Key Establishment protocol: Should that be:

   The NTS Key Establishment (NTS-KE) protocol

Similarly, please use consistent capitalization in "NTS Key
Establishment" v. "NTS key establishment".

Ditto for "NTS-KE Record Types" v. "NTS-KE record types".

Should 'NTPv4 protocol' be 'NTPv4 Protocol' in a number of places?
There are other, similar cases (NTS-KE protocol).

6.1 Key Extraction.  Sorry - I'm not seeing the email where it was
described why 2 keys (C2S and S2C) are useful, as opposed to a single key.

6.2. Packet structure overview

NTS as described offers two types of protection, DTLS encapsulation and
NTS EFs.  Does this section apply to both?  If not, please be more clear.

NTS should use a SINGLE Extension Field type, and the different modes
should be EF Codes.  See draft-stenn-ntp-extension-fields-01.

6.5 NTS Cookie Placeholder: Will there never be a use-case for data in
the cookie placeholder?  If this is a possibility, then it would be
sufficient to change the last sentence to "The contents of the NTS
Cookie Placeholder EF's body are undefined."  The bit about length
checking is handled above this layer.

I'd find it easier to navigate the document if, instead of:

6.3 Unique ID
6.4 NTS Cookie
6.5 NTS Cookie Placeholder
6.6 NTS AEE

that we use this instead:

6.3 NTS Extension Field and EF Codes
6.3.1 Unique ID
6.3.2 NTS Cookie
6.3.3 NTS Cookie Placeholder
6.3.4 NTS AEE

It is wasteful to burn 4 EFs for NTS when we can use 1, which is how EFs
were designed to be implemented and used.

6.6: we must address RFC7822.  The padding language in this section is a
prime example of why we must rescind RFC7822 and advance
draft-stenn-ntp-extension-fields-01.

6.7 Protocol details: NTS protection applies to both DTLS and NTS-EF
traffic.  The document states that NTP over DTLS will not use NTF EFs.
Please use more precise language wherever "NTS protection" is currently
used.  Perhaps "NTS EF-protected" instead of "NTS-protected".

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!


From nobody Sun Sep 17 23:58:48 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 BFBD613308C; Sun, 17 Sep 2017 23:58:47 -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 fNm1ByOe5uQr; Sun, 17 Sep 2017 23:58:46 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 B6E3E124319; Sun, 17 Sep 2017 23:58:45 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id w94so16256801ioi.7; Sun, 17 Sep 2017 23:58:45 -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=DTrCQF0MnpE9Wz0VgSc73l4Gs2T1N9091cptQHQFm4s=; b=O2B1GiOP8QOXnmR9SeMBR7Rn6ND/PjPn4IdZS76g3o7kasVVD6zJYRad/nAw+xAqux hPN16MWYRrc7bz+kg8vJ4yJ2yJR+fhPd3lMxtvavsTiBFR1IzjLoKG0g4TIabfb2Y8N7 rQR2QTq4jGf1cT/yokwwW6IZgauvd/V7jUl+ZfAVwdsgY88SqxjQJYpGGelHj/Zeu1JE LdPh7WqKrVuSO+M290zibf6V3lgLYxZ+6hrVgORz7kOjWF2bGvqNcrQpt9c+xuhpfmfp Mg/E+rqlXyL0KQ5lzP2qzWjgcZz/1NM9nLC+tTipi86dP++fgmSeFqLRCZ4wZ7jZ0Pma jRAw==
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=DTrCQF0MnpE9Wz0VgSc73l4Gs2T1N9091cptQHQFm4s=; b=mU8xV1WuRFZwg1SCHmnbWkfTLe7Qwh4PIiycj5/butIw3OgoEc8qc2xvPHODVdt20r 0Qay5wRvZ0zJdyCsK9CwqRP6eNq4v5qTFvsv68Iba6fU8UWz+EbzA2Vd79MvcvVt0rZO NCJoI7W7GjlJ4Mc7eSt745EXM4CAhoYa8VSt23O/MRuvf0zoMWWqEEhVVWlI9KUQxdbH xFpMAPgVR2s4bsNSazHP/C3+42SPUuYbypmb3P+UdF0zmFGYnDxmLqk2Xs+nndc19bm4 XfMAcdOUKpo3tHQG4fJjyFwhSA0rSa1eM/1l8Vg5xPoTj9KNuh43DxG1BD747UKrfaLu hKIQ==
X-Gm-Message-State: AHPjjUiorUP3739jUcQiqe+bVptqYOmi7Tw23lYJ045z8sKmkP3uxYd6 DadIaQcej0d+qCd/jRqWL83i8VQpYVC8SyV0zyYg3Q==
X-Google-Smtp-Source: AOwi7QCafkaEMMSmXhTTy4dNVuE1+5O9JDSZk/PQRLyKOkV/EpMrGCpwvQuSrJZFbyLlCdhb7qsLJHfq1xBthqYmjY4=
X-Received: by 10.202.10.1 with SMTP id 1mr34753145oik.221.1505717925148; Sun, 17 Sep 2017 23:58:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.168.181.200 with HTTP; Sun, 17 Sep 2017 23:58:44 -0700 (PDT)
In-Reply-To: <2D6594B3-2C10-4B65-B789-788A2DBF8E30@isoc.org>
References: <2D6594B3-2C10-4B65-B789-788A2DBF8E30@isoc.org>
From: Tal Mizrahi 
Date: Mon, 18 Sep 2017 09:58:44 +0300
Message-ID: 
To: "Karen O'Donoghue" 
Cc: "tictoc@ietf.org" , "ntp@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113c58580f7a570559714645"
Archived-At: 
Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
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, 18 Sep 2017 06:58:48 -0000

--001a113c58580f7a570559714645
Content-Type: text/plain; charset="UTF-8"

Hi,

I believe this draft is almost ready to proceed to the IESG.

Other than the YANG format issues that have already mentioned on the list,
I believe the Security Considerations section should be slightly extended.
- "Some data nodes defined in this YANG module are writable, and any
changes to them may adversely impact a synchronization network."
  Please elaborate about the consequences, i.e., what is the impact on the
network (Clock inaccuracy? Loss of synchronization? Other consequences?).
- The section should probably mention that the security considerations of
time protocols in general are discussed in [RFC 7384].

Cheers,
Tal.


On Wed, Sep 13, 2017 at 10:16 PM, Karen O'Donoghue 
wrote:

> Folks,
>
> This message begins a 2 week working group last call (WGLC) for the
> following document:
>
> YANG Data Model for IEEE 1588v2
> https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
>
> Please review the referenced document and send any comments to the mailing
> list including your assessment of whether this document is mature enough to
> proceed to the IESG. Please note that these messages of support for
> progression to the mailing list are important and will be used to determine
> WG consensus to proceed.
>
> Please send all comments in by Thursday 28 September 2017.
>
> Thank you!
> Karen
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>

--001a113c58580f7a570559714645
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I believe this draft is almost read=
y to proceed to the IESG.

Other than the YANG form=
at issues that have already mentioned on the list, I believe the Security C=
onsiderations section should be slightly extended.=C2=A0
- "=
Some data nodes defined in this YANG module are writable, and any changes t=
o them may adversely impact a synchronization network."
=C2=A0 Plea=
se elaborate about the consequences, i.e., what is the impact on the networ=
k (Clock inaccuracy? Loss of synchronization? Other consequences?).
- The section should probably mention that the security considerations o=
f time protocols in general are discussed in [RFC 7384].

Cheers,
Tal.


On Wed, Sep 13, 2017 at 10:16 PM, Ka=
ren O'Donoghue <odonoghue@isoc.org> wrote:
Folks,



This message begins a 2 week working group last call (WGLC) for the followi=
ng document:



YANG Data Model for IEEE 1588v2

https://datatracker.ietf.org/doc=
/draft-ietf-tictoc-1588v2-yang/



Please review the referenced document and send any comments to the mailing =
list including your assessment of whether this document is mature enough to=
 proceed to the IESG. Please note that these messages of support for progre=
ssion to the mailing list are important and will be used to determine WG co=
nsensus to proceed.



Please send all comments in by Thursday 28 September 2017.



Thank you!

Karen

_______________________________________________

TICTOC mailing list

TICTOC@ietf.org

https://www.ietf.org/mailman/listinfo/tictoc




--001a113c58580f7a570559714645--


From nobody Mon Sep 18 10:05:12 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 D0AFF133188 for ; Mon, 18 Sep 2017 10:05:09 -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] 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 MQw4x6WPBWUq for ; Mon, 18 Sep 2017 10:05:08 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7B0132D4E for ; Mon, 18 Sep 2017 10:05:08 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8F3D088129 for ; Mon, 18 Sep 2017 10:05:08 -0700 (PDT)
Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 558B33280AE4 for ; Mon, 18 Sep 2017 10:05:08 -0700 (PDT)
References: <150575413583.15695.17336571829984618139.idtracker@ietfa.amsl.com>
To: ntp@ietf.org
From: Brian Haberman 
Message-ID: <71289c4f-656e-d4c0-bc30-dcc1135db5d3@innovationslab.net>
Date: Mon, 18 Sep 2017 13:05:01 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150575413583.15695.17336571829984618139.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eWh0L0t1oit39PARVgw259PO1q9b7C6hJ"
Archived-At: 
Subject: Re: [Ntp] New Version Notification for draft-ietf-ntp-mode-6-cmds-03.txt
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, 18 Sep 2017 17:05:10 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--eWh0L0t1oit39PARVgw259PO1q9b7C6hJ
Content-Type: multipart/mixed; boundary="2pVUIivIc0SJ0kP2E9324T7tT0KVluB4X";
 protected-headers="v1"
From: Brian Haberman 
To: ntp@ietf.org
Message-ID: <71289c4f-656e-d4c0-bc30-dcc1135db5d3@innovationslab.net>
Subject: Re: New Version Notification for draft-ietf-ntp-mode-6-cmds-03.txt
References: <150575413583.15695.17336571829984618139.idtracker@ietfa.amsl.com>
In-Reply-To: <150575413583.15695.17336571829984618139.idtracker@ietfa.amsl.com>

--2pVUIivIc0SJ0kP2E9324T7tT0KVluB4X
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

All,
     This version addresses some minor comments received from several
folks. I will send out additional emails with the current outstanding
issues that need to be addressed.

Regards,
Brian


On 9/18/17 1:02 PM, internet-drafts@ietf.org wrote:
>=20
> A new version of I-D, draft-ietf-ntp-mode-6-cmds-03.txt
> has been successfully submitted by Brian Haberman and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-ntp-mode-6-cmds
> Revision:	03
> Title:		Control Messages Protocol for Use with Network Time Protocol Ve=
rsion 4
> Document date:	2017-09-18
> Group:		ntp
> Pages:		21
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-ntp-mod=
e-6-cmds-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-=
cmds/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-=
03
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mo=
de-6-cmds-03
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ntp-mode=
-6-cmds-03
>=20
> Abstract:
>    This document describes the structure of the control messages used
>    with the Network Time Protocol.  These control messages can be used
>    to monitor and control the Network Time Protocol application running=

>    on any IP network attached computer.  The information in this
>    document was originally described in Appendix B of RFC 1305.  The
>    goal of this document is to provide a historic description of the
>    control messages.
>=20
>                                                                        =
          =20
>=20
>=20
> Please note that it may take a couple of minutes from the time of submi=
ssion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20


--2pVUIivIc0SJ0kP2E9324T7tT0KVluB4X--

--eWh0L0t1oit39PARVgw259PO1q9b7C6hJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZv/zDAAoJEGjWPJxT0YthWlwP/RJjyeAnLbmmnsgGOSSdvY7F
6P/EOER5OUyQLujeTdSLpKlJArTOStq2OzH+IBU8OmI88ofUNACv4fD1brGVyM++
vu6mWjvXFl+2DMkrL6p9YjUsFC/W4lDKJDDg1hoiIo4ad6C2xgwizU0zlvu/0Whl
lVtWxmWgYmn4qmYjK8DQnh16BYnN3OUrXlqkCFdSM/L0Zdw4ac9BXeoLcfZhCrNB
bvZXNP/3xW+Owsj7DegQp9P0eLXDI96Hl3/YnXiJ/KAF5/IHvBI9ZS0sqP1pfRzB
zQiTqTd1gGquaIVgUl+qtvinZmyKcHKYEBEJIv4Cjj7gmKmhOquY6rps95bMiwxx
AfsPx/ZgSY3Qpppgguy826LEk7dNL52Xc/2zRsKX2HqUA+hVS0JxUAtF2XvKLX6S
5BtbMjuZmBomUoCUtT4jJ4XCL68w7dAopr8cioFQtthfzukDMHtPhukXXKmsLE7C
czxjy7tpn+B9/SEhjOcM8A4tLBy0Pf9wl6QyehfumHYPXJuw5KYM81aLdI9MHNeB
yKgijMmZRE48l2O9lMX5Hm3r2CA9N0bi8lw4+hTC0IAxdUAOe2GsFBzeT2V9t/mY
DAxSJ+Szied6NwI2N6SkGXLwWoDdZ1Gm1TdKSzis8vezBi4iQdaYk/TmDktSFo/S
CCBPV+Kt27dWLl4JsEq+
=OU85
-----END PGP SIGNATURE-----

--eWh0L0t1oit39PARVgw259PO1q9b7C6hJ--


From nobody Mon Sep 18 10:10:41 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 D75921342C7 for ; Mon, 18 Sep 2017 10:10: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 FgwS8xjq6xUl for ; Mon, 18 Sep 2017 10:10:38 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB97B1342BE for ; Mon, 18 Sep 2017 10:10:38 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C152D88129 for ; Mon, 18 Sep 2017 10:10:38 -0700 (PDT)
Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8BAD03280AE4 for ; Mon, 18 Sep 2017 10:10:38 -0700 (PDT)
To: ntp@ietf.org
From: Brian Haberman 
Message-ID: 
Date: Mon, 18 Sep 2017 13:10:37 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B4RTHBSxWOUW5x80EqPGCATestA3VRSf4"
Archived-At: 
Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 1
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, 18 Sep 2017 17:10:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--B4RTHBSxWOUW5x80EqPGCATestA3VRSf4
Content-Type: multipart/mixed; boundary="8WTxcR382aIX4gLBBjHprTeFS9m8PTX7t";
 protected-headers="v1"
From: Brian Haberman 
To: ntp@ietf.org
Message-ID: 
Subject: draft-ietf-ntp-mode-6-cmds : Issue 1

--8WTxcR382aIX4gLBBjHprTeFS9m8PTX7t
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Ulrich noted that this document does not specify a version number for
the mode 6 commands. I had suggested specifying it as "version 4 (or
earlier)" given that the introduction of mode 6 commands has occurred at
various versions of the protocol starting at RFC 1305. Ulrich pointed
out that the version number drives the interpretation of the status words=
=2E

For people who have implemented or use mode 6 commands, what makes sense
here? Do we need to specify a version number per mode 6 command?

Regards,
Brian


--8WTxcR382aIX4gLBBjHprTeFS9m8PTX7t--

--B4RTHBSxWOUW5x80EqPGCATestA3VRSf4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZv/4NAAoJEGjWPJxT0Yth18sP/3d1LWBpEedjJzqVnDO1fPFQ
WDLhzyc7Fgfibd34LbL0/U7UczZk5HlVkCB/m6+pbs44TdFkKCXLplzisJWKV5jQ
afOO9YD/WGuyDfr8727S98Mos6Se9/4O2rLhS4rFu4V8sbJ7CI255mSd8ZOEfCvq
N7DhXkNxJxlkDCv4XCGzDzvDRiJXF04WAqWeeevs/Z6+KXyA4Yt2p3EMVEDL+gtV
yvYlZ/RTL+mwxWt6FIVefAMTxVsmjrk1dq8GC7LpAlK1Od8JJJZlTq8Kr0m28dYP
MwgASm7jU1e8arcf3g6yAjMjd9ZMXxIM3xPVAChv2114se35tPSlZw8f3KveGTxP
VUW1ErR5yDhW5U8bI5X6QekuWQwBlnRT4M/+EEFvxT5V9O8FJ3mgwBrXvv3089V0
u/Ihsh2of+8tmByWZNRyzgo6J+LBC5z7YaxQTmCanY9TdqDvFzetjIjTu6W9a1GH
LxC3zjQqH4kmtm5jj/qmkZ26Lr3Zp9YPqkLkOfYsUmzy1L1O8c0BgNLtJUqwyukw
1inje3fmH3KmxxhFxYgXG36ANF7Jbpi/VngLw5D8KDXFjfQSoFsMh36WqMru4Dke
fkvakOLvdUflw9mr5IIGw4KOVqi0nznXvgD6aqwVUKItEuKDFk5ffolrILuAJz+t
og+Qn20Kzhf3m4CTEoVL
=02MD
-----END PGP SIGNATURE-----

--B4RTHBSxWOUW5x80EqPGCATestA3VRSf4--


From nobody Mon Sep 18 10:13:44 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 8B3B61342F1 for ; Mon, 18 Sep 2017 10:13:40 -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] 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 cnRyPfk5537M for ; Mon, 18 Sep 2017 10:13:37 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DDD1342E6 for ; Mon, 18 Sep 2017 10:13:37 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3912188129 for ; Mon, 18 Sep 2017 10:13:37 -0700 (PDT)
Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0496F3280AE4 for ; Mon, 18 Sep 2017 10:13:36 -0700 (PDT)
From: Brian Haberman 
To: ntp@ietf.org
Message-ID: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net>
Date: Mon, 18 Sep 2017 13:13:35 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0nVT514TE8Vm2lvOqvP1vL089PIWmW50r"
Archived-At: 
Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
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, 18 Sep 2017 17:13:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0nVT514TE8Vm2lvOqvP1vL089PIWmW50r
Content-Type: multipart/mixed; boundary="kIxUCmKhHJJDopcxCEwAiIfGJIwaccNqW";
 protected-headers="v1"
From: Brian Haberman 
To: ntp@ietf.org
Message-ID: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net>
Subject: draft-ietf-ntp-mode-6-cmds : Issue 2

--kIxUCmKhHJJDopcxCEwAiIfGJIwaccNqW
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Ulrich noted that there is currently no easy way to discover the version
of the NTP server being interrogated with mode 6 commands.

For people who have implemented or use mode 6 commands, do we want to
specify a mode 6 command that determines the version of the server being
queried?

Regards,
Brian




--kIxUCmKhHJJDopcxCEwAiIfGJIwaccNqW--

--0nVT514TE8Vm2lvOqvP1vL089PIWmW50r
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZv/6/AAoJEGjWPJxT0YthQYAQAKWd0ryrJqRFH3//9vlf0N5b
DhI3pK0FaKmp7ew/7GwrcwPqn/FGv+g2JQOko/3o+5t7wpidzVZOiff4b8rUgId4
oGLpSehaPMGB1SiwX8KmUpn5is4kvXtypXXiQPeIEL65pIoFAC/HLOjTtS4PKWkG
klB6yVxgHAAOu3Px3NZsSVzxq2Mc1FhZK5HiRqgY8zD9EeLeWkrXIYucr703Nqnj
0oidQ/fZzURw6UW/KPyOjkWjmmG+T9XdMFfIvKqZR0NTz38/stVra+ywRTbQor47
3YgQq7itLRNLG7F30iibkvBvYXGmSbjx8z2UYavzaLB4esykRR3EoZeUWj1OevEW
LvjM4rp1xb6AY0kaHi+2bytn3yR22xibv4yXb/TWqTdUU29e6aU5hDjWTRsFQLPu
ZMDs3x+wkvOjnwcHyb37iWzHU/yfAd1t/ClfCqSYxmpY1t2e7wetKMOalXtdSPZQ
PsvpYZzV4ramfxdz5RbdplM5yRbtp1aLV3iD2khLObTm0oVLIsqGdizXjK/EB5pt
KWKVvk8+arpCLOwhPYXAyA8BqBVdJ9vPcyq6tPaiBOdRIW+iTsaWa11DVlujq3yF
5Zpy7lzlW5WN4mFej00IJkmkYGz6xNkVfsza0oswHCaUJKciaFr2clFf1UxyZR/v
NN/CbrEcdDRXEPYgkPN2
=8Ota
-----END PGP SIGNATURE-----

--0nVT514TE8Vm2lvOqvP1vL089PIWmW50r--


From nobody Mon Sep 18 10:35:30 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 81B60133018 for ; Mon, 18 Sep 2017 10:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 tPHJOP3aZcxo for ; Mon, 18 Sep 2017 10:35:24 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0088.outbound.protection.outlook.com [104.47.41.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B731132992 for ; Mon, 18 Sep 2017 10:35:23 -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=N5ejvB8K8dtxvn+PUb6WxokxeKgOgcg8ryRgywyggZQ=; b=LdDBsPA90Of1stVDI4HXNe0qZNLSPvFFw6wNguVwjQ8GnDiW5wyovII2bXTryyf0VRmfonLalAmoHs0rOlikK3ZWGf/Fq5lVEwyMTH2/swts2EkgaBRzaaye7iO8YLwzepUyd41bc2WXyqFIgMdwRslp83+tCJP9tW4qf01kTng=
Received: from BN6PR02CA0026.namprd02.prod.outlook.com (10.173.146.140) by DM5PR02MB2204.namprd02.prod.outlook.com (10.168.173.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 18 Sep 2017 17:35:22 +0000
Received: from BN1BFFO11FD044.protection.gbl (2a01:111:f400:7c10::1:102) by BN6PR02CA0026.outlook.office365.com (2603:10b6:404:5f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.8 via Frontend Transport; Mon, 18 Sep 2017 17:35:22 +0000
Authentication-Results: spf=pass (sender IP is 208.19.100.21) smtp.mailfrom=microsemi.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=microsemi.com;
Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.21 as permitted sender) receiver=protection.outlook.com;  client-ip=208.19.100.21; helo=avsrvexchhts1.microsemi.net;
Received: from avsrvexchhts1.microsemi.net (208.19.100.21) by BN1BFFO11FD044.mail.protection.outlook.com (10.58.144.107) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.35.14 via Frontend Transport; Mon, 18 Sep 2017 17:35:21 +0000
Received: from AVMBX2.microsemi.net (10.100.34.32) by avsrvexchhts1.microsemi.net (10.100.34.105) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 18 Sep 2017 10:35:08 -0700
Received: from AVMBX2.microsemi.net (10.100.34.32) by AVMBX2.microsemi.net (10.100.34.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1034.26; Mon, 18 Sep 2017 10:35:08 -0700
Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by AVMBX2.microsemi.net (10.100.34.32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1034.26 via Frontend Transport; Mon, 18 Sep 2017 10:35:08 -0700
Received: from SJSRVEXCHMBX1.microsemi.net ([fe80::19b5:ac43:d8de:5120]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 10:35:07 -0700
From: Greg Dowd 
To: Brian Haberman , "ntp@ietf.org" 
Thread-Topic: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
Thread-Index: AQHTMKHIsMe6CrL2UkmPHiTL4zLL+6K652kA
Date: Mon, 18 Sep 2017 17:35:06 +0000
Message-ID: <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net>
In-Reply-To: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:208.19.100.21; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(2980300002)(438002)(5403001)(199003)(377454003)(189002)(13464003)(97736004)(53546010)(478600001)(72206003)(23676002)(230783001)(7696004)(106466001)(2950100002)(69596002)(6246003)(2906002)(229853002)(316002)(110136005)(6116002)(102836003)(2501003)(3846002)(2900100001)(2920100001)(305945005)(356003)(7736002)(68736007)(9686003)(53936002)(53416004)(5250100002)(54356999)(76176999)(50986999)(8676002)(8936002)(47776003)(86362001)(189998001)(33656002)(81166006)(81156014)(55846006)(50466002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR02MB2204; H:avsrvexchhts1.microsemi.net; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD044; 1:L7uteph0+0z4RuXpfRmayuSE5evur/Sir1VZD1bBAkbzvRHLmqLrBIUMeSGE3wxSRRiVLg0O3d6hXTpfF6Qx6g4sVYRrbtVvSWJKOpDA66ZxH+kibmfopIRK4STxJVI0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ab2d6c96-0cd7-489c-3061-08d4febba37d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR02MB2204; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR02MB2204; 3:HpPJvfTS1/PSYgn7zNhhQcrxc4F+ub3gEH8/5h1bpTHSkFIMbDJGSta1YOaFtWlj2eTLC6AnQ7XqhB0ekXbNhme69m1aZGIpcN98Tr5QgxWVYGRzTJmtR4UWKD6bAqPqZKJwLU1vBVo/3m6qkoEYCK+lKo7g84XPDLc8udDk0ioR2tsEHrrwE9Abfv1YWGCHZYXqRQNTzFMFPwAMrvl4ZBDJu9e8DiK0np/CinxiiG0EczB+9KzC4pIYhul+NRrKOibSyeOkXIpOYorOop0sqTGdiQAXV47f8IMatkZ1t3X1dbgFEwMNzCq8uSlyMcteOfNRL0hLFKUBneS+2TtrNWWsIpHgQBTuTmJqxgaa5ic=; 25:r9BL7m/HEOidpps6mAF0p3YRjUfc1OrNU++0VF4Jj7IPIJ/n5Sl1MJQJJdfq2fhqmdUqXLCV1eVWUZGGQEJgZWVXx5/qRBdn2Lwgyyyhd+KHXnTEZffod81pDjGw6o5Y38GXn+gVgyVAcrq+CztuihgaeVHhRS1Lj2hp/vzj/SSjjERKl7R8Qoxnr+98t93IaEADJ2SVvz9Y5G6YbRi3WIcGJ99mbTBOJU5lD7fjIsDTmqAJnbudcWrVJzkjoPTFdmfFaUGTO+/xVaHRcnsvz6fjgn0tGHkfnQdd4HlUGFOL8KM2j1RQ6jD4VL2tvEYEoxjMFa/H/3/VZzy5Yy7oPw==
X-MS-TrafficTypeDiagnostic: DM5PR02MB2204:
X-Microsoft-Exchange-Diagnostics: 1; DM5PR02MB2204; 31:ly0teuLp6kwGy6WPp6R1RkJjFGCqi6kA4x+fJmMO2MQ9mZ5Dhfa7O1W1tOgJ0fo0cUpNNzawcowXRzbhyNr98t8gc0ufOfUlbtlJUaICgzU757l72KUATqKrGMH2Ph11QCkrW99YyfB984on/pZJLvaDNrcFoPyzce187dk/CIXOfIAzqd1X7f72rOQDnR0CHNsyzwcc6Kfh+UNKx4J7ERze+lh6rMShCTYXQbXbbBI=; 20:3Ce1HDLW5wKAaMq+rQJ2QHzyVPldgL773ubFBeZGCFefMzT+7S/FVghOl8ogN1dMBS36lbydt4wVyq1PTVFnOEeKQLuETAt7AGwV4z8vlgIzDcGpXJoPmHuSRh2hMuVen3Vy+dZikBJdvEYEb4w9NtBmfjk0BYHtEbgeb/CkxTp4GQrIi0iNyH71Y+Z6LZTk8SqKRhQgG/Hc3jR1O26w7yTSnsiXAHbDHk5MhIIn6DRrcbw6NpCgUEZMBIvxYD/BI+fNd7FwCZJpjz+R3DHyfp36W8qzzIw4avL9Ju1DlaFojv0D+HGyEnSfxTwNVID0bgRWFRSeCZCWXg+qA/wt44lZFVjxgF1UworqX7Vw+WgxUjuND1INxv1BgH4qjohnNX1M7aP/Zexuj+x6UFuhqFd5jPk5fFn2/pB5T5FD2rduPMq1EhqbIIxsD3OdprcMTMGFDzAfgpCc/CKwRZp0sT0ef75qj07JhTIrWIJ/JSaKqatPCLjvszQbyxXaE+3J
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
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)(3002001)(93006095)(93004095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR02MB2204; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR02MB2204; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR02MB2204; 4:oE5EgJ4wuDVO6uEojPLgFgwW0Zbf33gDGLqOeJZjouPlpy8clmwio9XbQhGzuu14Vx9qZkNgc4IXIJlqc1uxejM2qjpsQgTyWXNLxVLck7TtSrujWSJo3Uxmd/AvvD3HFe16xU90nLlmoq4nIgEUQpeLX+9mgx1TyAz/f8XBHHadM/DxgHama5pc+2kklW/ifogZzCbkUgCfAysDjVehDrZohn0CEdPXxtfLmd2U+AItPOJmCYmHrzXwilUk/8EkKqOLa2LWZ7miO4zz92BZCLdcqEtZ0NZ0OdOu4j5XbgY=
X-Forefront-PRVS: 04347F8039
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjAyTUIyMjA0OzIzOnAvbVZTZWxJcGlWdnNPbGFwaWlHSlk5WVoz?= =?utf-8?B?dTRxT3pIdXhWRWRJeVZzVU56ckVYUnBqTTZzWllWS0IvKzVNdElxdjhZZW5q?= =?utf-8?B?enh3QjNDYk83dFFHTEZGTHhvRExyVThZcjZDY1FUK21FMGVvaURzMHJQQ2R4?= =?utf-8?B?SHlKR2lVcUZ5QU5HOXozZ0FESTZXYjVQdUJXM0x1RHZnMkdNZmhxM1VoVW02?= =?utf-8?B?enN5c291bXJ4ZkRCM2xqbisvei81WTFmVDJ6czdGY3F5aE5yc2M5N0UrMVpv?= =?utf-8?B?UnowaW92cmRDMXF0OGJ5ZVBCUDZLbnJQdUNGdmNGb0wxS3A0MmVDclNmUFNF?= =?utf-8?B?cnJ1S3c2ZStkdTgvUlY2Ni9xc0FnVm1LS2pZdDZpRy9xWkhTbzlEczc2enhN?= =?utf-8?B?NmNnN05tYjNsUi96dDUwUUp5UExPTXZoUGVBaXIzaUxlZ1l0QStHRWlBUTNJ?= =?utf-8?B?ZnFsbWtZM3VPazcyWXJQOEFKTS9meFkzR25aNGI2aHFaclltSUw4MjhGbVNU?= =?utf-8?B?NXp0MU1iUys1eDlrTnBRSG5nbTBmWEJCbmx6ZkdLb1JvQUhUZUtGdE4wK2ty?= =?utf-8?B?d2lSK3o3QnBWVWJGL3ZGZk1KMTEvQXFKMmtHYlU2Y3l0QmdmYS9oa2VWOXdJ?= =?utf-8?B?ZU9WZ2phRE9XR1M0d1lvWU1pQU1EcHE2WDJyWGlLTVZKMGtQV3JNdURNZTRF?= =?utf-8?B?dVF2YlV3cklFbkRsQ0pSWHVxOXdybkpmeTZHeFV2WU51OUlpZDFUaFVrc2ZK?= =?utf-8?B?U2cwaGJRY3NPYnBMeWNLeFpEMGZrU1dvRi9DV2hVUXBjQ3lMUlYvWW5LUUox?= =?utf-8?B?RkJqL0NEdDNkdEdRTVQ3ZEdXc3daaDIzd0dNSWMzaFAxSTlsbUxBNE9nekhB?= =?utf-8?B?NGZWSHlmOXZnUWYwRW5EVUh0Q1l4OU5hbmpUNkFmazFzRGp4SmpPZVdpWHV3?= =?utf-8?B?Si9pSTdUWDNSNTdGdlJrYm5JdHZEaGhBVE10SHVKSVIrbm4wREFqOWZmamw5?= =?utf-8?B?NmpyVDRldXAxWmVVVEY1R0hGanpLNlN3cFR4ZTZLaUtWUm9wNWd5TWdyTUdr?= =?utf-8?B?cEZMNGtMZXhJaFBLVWZJNjRoQmNrbzdEYVI3L0pvNlcwcDRwa2YzRHU3MXZ4?= =?utf-8?B?UG1zSG5LaW10Mnh4RVh4eU81cGRYV0ZSRk9NcWV3Y29aU1RkMXJXcEZ5Qzd0?= =?utf-8?B?UnZ2NVJjNHpMS2tnN2IrNkh0eTNTbGo3SzVxM1J1dmc2bjRDaGZpT001VDhs?= =?utf-8?B?aFNxRFZXVU9WOE42T2JPR3RDbElqYmQ4QkpwY1paeTliQ1hudWo4MXNjWHly?= =?utf-8?B?UENsYnRJSDg5RjdYaHFlT3RwZFUwbEVYc0g3WDZxb2JjWXd2L1I1Kzc0ZXJv?= =?utf-8?B?NWpldkhFcXBqVmFuYVRyd2pFR3VVNnhUZ2IzQ3ZoaTlYL0dMc0RQTEhPOWFK?= =?utf-8?B?Q0pjODM1T3ZValNKS1BKV1ZkZkV3bmo1c0p3TEt1UnpFNG5oVS9Xc3U5NGp5?= =?utf-8?B?cFRLZEhtUE9ZOEJ2bXVTNjY2ZVRQZzRJNVF5Tzc1WjBnOEY3RUxzZGZIMWV3?= =?utf-8?B?K1VxRzk1K04ySFMvaXI4K2ZRVzd0QlJOR0lEVi9kQXNXS0JoWWg0bWFXWW5I?= =?utf-8?B?SHg5clJQc2lieEMyOTRTWGRJanlXNGNFU3NUQjg3UG8veTVjZ3ZSUmYrbVJ3?= =?utf-8?Q?YDgV9SGkduF3fRLiXwB/XCL5upDaYTU8cLrbSVt?=
X-Microsoft-Exchange-Diagnostics: 1; DM5PR02MB2204; 6:IzZKpZqs5Tzi9WlO3fvnrZalfGNYZKuF2vxTvoip3TP0+rYtnyTIJ7tAx4sx/XlErO9JgmCvtd8HuxsBEV08p/ZJLCaeQRbNEhL4ahsAjnA34OdoXEgSLkalsJouPpk7MtBlHgF53GhvX5Teok0dyANeQK5cywZyeygcQiMNI1h3/Bmc4GWfJ0QIKvX7I+vCt0Z9OpRxBsYEAv68EE0O/jGnrbYYtFL7m4r/FMIaZY3nh/mctf20SV/pUGr4DWt5ceRaRlRxfZjFmummdBOrlhqswI2HXed33hGvKn/o+fb7OY3l3MmTpSowNsauLrnwuwDQLrzmHA13oeU5sdNufQ==; 5:HdxFjSVIXwjUKV5XrvbErntZOumJTHZSF4Ap5GOQma4iFRTwWxYJQUFATGfv/hDP8Y26sfasNNOH3CH0rJVAOsEPc1KeV+QAlYBnBY4hcT6wbXdOOakQm0lR+w8tcnmHd2qqU7qZyEHJegBj+bGvnA==; 24:UcPVwY9iWzLH4kjKmnzUkgDOlOpym7/T8AWieoEK6hrMXwQrGGgtXfl184UobFAaaAUix5SiYsDn/Il0Yqm7t9m9WcTLHA7fQstwfKactEs=; 7:4X8Yu6E7mCe5IoWmTnHK+bmL7HXJVzmS4eNTuAezf28psH4PGEAjy4sp5/JEaax5Z2o7KmW68d2JxsA3WZadr8bQQNCCfIgxQvKTw0RTjqu9g/OAwLXBnc8Mdvvt5triMZC0TFA1OLn+7rNzEGjLmIvHzNH7PEqUmIWA62XQpzIvbCLxOSyk348cdp8j1ZLn++ecSxy1gHjFBTLfu6BGCPkYwjg0IlaE8XX3laMQFPg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: microsemi.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2017 17:35:21.7724 (UTC)
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.21];  Helo=[avsrvexchhts1.microsemi.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2204
Archived-At: 
Subject: Re: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
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, 18 Sep 2017 17:35:27 -0000

QXMgYSB1c2VyLCBJIGRvbid0IGhhdmUgbXVjaCB2YWx1ZSB0byBhZGQuICBPdXIgdHlwaWNhbCB1
c2UgY2FzZSwgd2hpY2ggaXMgcHJvYmFibHkgcHJldHR5IHdpZGVzcHJlYWQsIGlzIHZpYSBsb29w
YmFjayBpbnRlcmZhY2Ugc28gdmVyc2lvbiBpc24ndCBtdWNoIG9mIGFuIGlzc3VlLg0KDQpUaGFu
a3MuLi5HcmVnDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG50cCBbbWFp
bHRvOm50cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gSGFiZXJtYW4NClNl
bnQ6IE1vbmRheSwgU2VwdGVtYmVyIDE4LCAyMDE3IDEwOjE0IEFNDQpUbzogbnRwQGlldGYub3Jn
DQpTdWJqZWN0OiBbTnRwXSBkcmFmdC1pZXRmLW50cC1tb2RlLTYtY21kcyA6IElzc3VlIDINCg0K
RVhURVJOQUwgRU1BSUwNCg0KDQpVbHJpY2ggbm90ZWQgdGhhdCB0aGVyZSBpcyBjdXJyZW50bHkg
bm8gZWFzeSB3YXkgdG8gZGlzY292ZXIgdGhlIHZlcnNpb24gb2YgdGhlIE5UUCBzZXJ2ZXIgYmVp
bmcgaW50ZXJyb2dhdGVkIHdpdGggbW9kZSA2IGNvbW1hbmRzLg0KDQpGb3IgcGVvcGxlIHdobyBo
YXZlIGltcGxlbWVudGVkIG9yIHVzZSBtb2RlIDYgY29tbWFuZHMsIGRvIHdlIHdhbnQgdG8gc3Bl
Y2lmeSBhIG1vZGUgNiBjb21tYW5kIHRoYXQgZGV0ZXJtaW5lcyB0aGUgdmVyc2lvbiBvZiB0aGUg
c2VydmVyIGJlaW5nIHF1ZXJpZWQ/DQoNClJlZ2FyZHMsDQpCcmlhbg0KDQoNCg0K


From nobody Mon Sep 18 16:33: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 6C994133073 for ; Mon, 18 Sep 2017 16:33:00 -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, 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 9ChensKweEzv for ; Mon, 18 Sep 2017 16:32:58 -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 7657C132981 for ; Mon, 18 Sep 2017 16:32:58 -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 CB72BB873; Mon, 18 Sep 2017 23:32:57 +0000 (UTC)
To: ntp@ietf.org
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net> <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>
From: Harlan Stenn 
Message-ID: 
Date: Mon, 18 Sep 2017 16:32:58 -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: <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
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, 18 Sep 2017 23:33:00 -0000

The protocol version is in the NTP header.  Granted, a V4 server can
issue V3 queries.

As for anything else:

- some will consider this sensitive information that should only be
  disclosed to authorized parties.

- we use: ntpq -c "rv 0 daemon_version"
  to query the daemon version.  There is no Standard way to get this
  information, and I'm open to an INFORMATIONAL list of system variables
  that folks might find interesting and/or useful.

H
--

On 9/18/2017 10:35 AM, Greg Dowd wrote:
> As a user, I don't have much value to add.  Our typical use case, which is probably pretty widespread, is via loopback interface so version isn't much of an issue.
> 
> Thanks...Greg
> 
> 
> -----Original Message-----
> From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Brian Haberman
> Sent: Monday, September 18, 2017 10:14 AM
> To: ntp@ietf.org
> Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
> 
> EXTERNAL EMAIL
> 
> 
> Ulrich noted that there is currently no easy way to discover the version of the NTP server being interrogated with mode 6 commands.
> 
> For people who have implemented or use mode 6 commands, do we want to specify a mode 6 command that determines the version of the server being queried?
> 
> Regards,
> Brian
> 
> 
> 
> _______________________________________________
> 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 Mon Sep 18 16:37:02 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 52BB1133055 for ; Mon, 18 Sep 2017 16:37:00 -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, 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 mknib1j7Wij1 for ; Mon, 18 Sep 2017 16:36:59 -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 01917132981 for ; Mon, 18 Sep 2017 16:36:58 -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 BB440B864; Mon, 18 Sep 2017 23:36:58 +0000 (UTC)
To: ntp@ietf.org
References: 
From: Harlan Stenn 
Message-ID: 
Date: Mon, 18 Sep 2017 16:36:59 -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: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 1
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, 18 Sep 2017 23:37:00 -0000

On 9/18/2017 10:10 AM, Brian Haberman wrote:
> Ulrich noted that this document does not specify a version number for
> the mode 6 commands. I had suggested specifying it as "version 4 (or
> earlier)" given that the introduction of mode 6 commands has occurred at
> various versions of the protocol starting at RFC 1305. Ulrich pointed
> out that the version number drives the interpretation of the status words.
> 
> For people who have implemented or use mode 6 commands, what makes sense
> here? Do we need to specify a version number per mode 6 command?

I've long wanted a way to identify more information about information
about what information is available via mode6 commands, and the format
of that information.

While some of this information is part of the "core", a lot of it is
implementation-specific, and can easily change from one code version to
the next.

I don't think we want to cast any of this into concrete.

On the other hand, we do need a way to figure out what's available
(which may changed based on authorization levels) and the format in
which it's presented.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!


From nobody Mon Sep 18 18:23: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 8219A126E64; Mon, 18 Sep 2017 18:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 RXScps78yPdi; Mon, 18 Sep 2017 18:23:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B23132331; Mon, 18 Sep 2017 18:23:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVS54142; Tue, 19 Sep 2017 01:23:52 +0000 (GMT)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 19 Sep 2017 02:23:51 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.79]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Tue, 19 Sep 2017 09:23:42 +0800
From: Jiangyuanlong 
To: Tal Mizrahi , "Karen O'Donoghue" 
CC: "ntp@ietf.org" , "tictoc@ietf.org" 
Thread-Topic: [Ntp] [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
Thread-Index: AQHTLMS9I02w6VlOokuuR++M6yrZg6K5t3wAgAG4GWA=
Date: Tue, 19 Sep 2017 01:23:41 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C1335@dggeml507-mbx.china.huawei.com>
References: <2D6594B3-2C10-4B65-B789-788A2DBF8E30@isoc.org> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C1335dggeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.59C071A9.000C, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.79, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 18bd5f0f5521daee44e198e34c13a4cd
Archived-At: 
Subject: Re: [Ntp] [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
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, 19 Sep 2017 01:23:57 -0000

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C1335dggeml507mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGFsLA0KDQogICBHb29kIHN1Z2dlc3Rpb25zISBCYXNlZCBvbiB5b3VyIGNvbW1lbnRzLCBJIHdv
dWxkIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0cyBmb3IgdGhlIFNlY3VyaXR5IGNvbnNpZGVy
YXRpb25zOg0KICAg4oCcWUFORyBtb2R1bGVzIGFyZSBkZXNpZ25lZCB0byBiZSBhY2Nlc3NlZCB2
aWEgdGhlIE5FVENPTkYgcHJvdG9jb2wNCiAgIFtSRkM2MjQxXSwgdGh1cyBzZWN1cml0eSBjb25z
aWRlcmF0aW9ucyBpbiBbUkZDNjI0MV0gYXBwbHkgaGVyZS4NCiAgIFNlY3VyaXR5IG1lYXN1cmVz
IHN1Y2ggYXMgdXNpbmcgdGhlIE5FVENPTkYgb3ZlciBTU0ggW1JGQzYyNDJdIGFuZA0KICAgcmVz
dHJpY3RpbmcgaXRzIHVzZSB3aXRoIGFjY2VzcyBjb250cm9sIFtSRkM2NTM2XSBjYW4gZnVydGhl
cg0KICAgaW1wcm92ZSBpdHMgc2VjdXJpdHksIGF2b2lkIGluamVjdGlvbiBhdHRhY2tzIGFuZCBt
aXN1c2Ugb2YgdGhlDQogICBwcm90b2NvbC4gRnVydGhlcm1vcmUsIGdlbmVyYWwgc2VjdXJpdHkg
Y29uc2lkZXJhdGlvbnMgb2YgdGltZQ0KICAgcHJvdG9jb2xzIGFyZSBkaXNjdXNzZWQgaW4gW1JG
QzczODRdLg0KDQogICBTb21lIGRhdGEgbm9kZXMgZGVmaW5lZCBpbiB0aGlzIFlBTkcgbW9kdWxl
IGFyZSB3cml0YWJsZSwgYW5kIGFuDQogICBpbmFwcHJvcHJpYXRlIHVzZSBvZiB0aGVtIG1heSBh
ZHZlcnNlbHkgaW1wYWN0IGEgc3luY2hyb25pemF0aW9uIG5ldHdvcmssDQogICBmb3IgZXhhbXBs
ZSwgbG9zcyBvZiBzeW5jaHJvbml6YXRpb24gb24gYSBjbG9jaywgYWNjdXJhY3kgZGVncmFkYXRp
b24NCiAgIG9uIGEgc2V0IG9mIGNsb2Nrcywgb3IgZXZlbiBicmVhayBkb3duIG9mIGEgd2hvbGUg
c3luY2hyb25pemF0aW9uIG5ldHdvcmsu4oCdDQoNCiAgQXJlIHlvdSBPSyB3aXRoIHRoZSBhYm92
ZSB0ZXh0cz8NCg0KVGhhbmtzIGEgbG90LA0KWXVhbmxvbmcNCg0KDQpGcm9tOiBudHAgW21haWx0
bzpudHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRhbCBNaXpyYWhpDQpTZW50OiBN
b25kYXksIFNlcHRlbWJlciAxOCwgMjAxNyAyOjU5IFBNDQpUbzogS2FyZW4gTydEb25vZ2h1ZQ0K
Q2M6IG50cEBpZXRmLm9yZzsgdGljdG9jQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW050cF0gW1RJ
Q1RPQ10gV0dMQyBmb3IgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcNCg0KSGksDQoNCkkg
YmVsaWV2ZSB0aGlzIGRyYWZ0IGlzIGFsbW9zdCByZWFkeSB0byBwcm9jZWVkIHRvIHRoZSBJRVNH
Lg0KDQpPdGhlciB0aGFuIHRoZSBZQU5HIGZvcm1hdCBpc3N1ZXMgdGhhdCBoYXZlIGFscmVhZHkg
bWVudGlvbmVkIG9uIHRoZSBsaXN0LCBJIGJlbGlldmUgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp
b25zIHNlY3Rpb24gc2hvdWxkIGJlIHNsaWdodGx5IGV4dGVuZGVkLg0KLSAiU29tZSBkYXRhIG5v
ZGVzIGRlZmluZWQgaW4gdGhpcyBZQU5HIG1vZHVsZSBhcmUgd3JpdGFibGUsIGFuZCBhbnkgY2hh
bmdlcyB0byB0aGVtIG1heSBhZHZlcnNlbHkgaW1wYWN0IGEgc3luY2hyb25pemF0aW9uIG5ldHdv
cmsuIg0KICBQbGVhc2UgZWxhYm9yYXRlIGFib3V0IHRoZSBjb25zZXF1ZW5jZXMsIGkuZS4sIHdo
YXQgaXMgdGhlIGltcGFjdCBvbiB0aGUgbmV0d29yayAoQ2xvY2sgaW5hY2N1cmFjeT8gTG9zcyBv
ZiBzeW5jaHJvbml6YXRpb24/IE90aGVyIGNvbnNlcXVlbmNlcz8pLg0KLSBUaGUgc2VjdGlvbiBz
aG91bGQgcHJvYmFibHkgbWVudGlvbiB0aGF0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBv
ZiB0aW1lIHByb3RvY29scyBpbiBnZW5lcmFsIGFyZSBkaXNjdXNzZWQgaW4gW1JGQyA3Mzg0XS4N
Cg0KQ2hlZXJzLA0KVGFsLg0KDQoNCk9uIFdlZCwgU2VwIDEzLCAyMDE3IGF0IDEwOjE2IFBNLCBL
YXJlbiBPJ0Rvbm9naHVlIDxvZG9ub2dodWVAaXNvYy5vcmc8bWFpbHRvOm9kb25vZ2h1ZUBpc29j
Lm9yZz4+IHdyb3RlOg0KRm9sa3MsDQoNClRoaXMgbWVzc2FnZSBiZWdpbnMgYSAyIHdlZWsgd29y
a2luZyBncm91cCBsYXN0IGNhbGwgKFdHTEMpIGZvciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0K
DQpZQU5HIERhdGEgTW9kZWwgZm9yIElFRUUgMTU4OHYyDQpodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy8NCg0KUGxlYXNlIHJldmll
dyB0aGUgcmVmZXJlbmNlZCBkb2N1bWVudCBhbmQgc2VuZCBhbnkgY29tbWVudHMgdG8gdGhlIG1h
aWxpbmcgbGlzdCBpbmNsdWRpbmcgeW91ciBhc3Nlc3NtZW50IG9mIHdoZXRoZXIgdGhpcyBkb2N1
bWVudCBpcyBtYXR1cmUgZW5vdWdoIHRvIHByb2NlZWQgdG8gdGhlIElFU0cuIFBsZWFzZSBub3Rl
IHRoYXQgdGhlc2UgbWVzc2FnZXMgb2Ygc3VwcG9ydCBmb3IgcHJvZ3Jlc3Npb24gdG8gdGhlIG1h
aWxpbmcgbGlzdCBhcmUgaW1wb3J0YW50IGFuZCB3aWxsIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIFdH
IGNvbnNlbnN1cyB0byBwcm9jZWVkLg0KDQpQbGVhc2Ugc2VuZCBhbGwgY29tbWVudHMgaW4gYnkg
VGh1cnNkYXkgMjggU2VwdGVtYmVyIDIwMTcuDQoNClRoYW5rIHlvdSENCkthcmVuDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVElDVE9DIG1haWxpbmcg
bGlzdA0KVElDVE9DQGlldGYub3JnPG1haWx0bzpUSUNUT0NAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpY3RvYw0KDQo=

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C1335dggeml507mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc
QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy
LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UYWwsPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyAmbmJzcDtHb29kIHN1Z2dl
c3Rpb25zISBCYXNlZCBvbiB5b3VyIGNvbW1lbnRzLCBJIHdvdWxkIHByb3Bvc2UgdGhlIGZvbGxv
d2luZyB0ZXh0cyBmb3IgdGhlIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IOKAnFlBTkcgbW9kdWxl
cyBhcmUgZGVzaWduZWQgdG8gYmUgYWNjZXNzZWQgdmlhIHRoZSBORVRDT05GIHByb3RvY29sPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgW1JG
QzYyNDFdLCB0aHVzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIFtSRkM2MjQxXSBhcHBseSBo
ZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i
c3A7IFNlY3VyaXR5IG1lYXN1cmVzIHN1Y2ggYXMgdXNpbmcgdGhlIE5FVENPTkYgb3ZlciBTU0gg
W1JGQzYyNDJdIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7Jm5ic3A7IHJlc3RyaWN0aW5nIGl0cyB1c2Ugd2l0aCBhY2Nlc3MgY29udHJvbCBbUkZD
NjUzNl0gY2FuIGZ1cnRoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOyZuYnNwOyBpbXByb3ZlIGl0cyBzZWN1cml0eSwgYXZvaWQgaW5qZWN0aW9uIGF0
dGFja3MgYW5kIG1pc3VzZSBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBwcm90b2NvbC4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k
OnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+RnVydGhlcm1vcmUsIGdlbmVyYWwgc2VjdXJp
dHkgY29uc2lkZXJhdGlvbnMgb2YgdGltZQ0KPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RDtiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxv
dyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvdG9jb2xzIGFyZSBkaXNjdXNzZWQgaW4gW1JGQzczODRd
Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg
U29tZSBkYXRhIG5vZGVzIGRlZmluZWQgaW4gdGhpcyBZQU5HIG1vZHVsZSBhcmUgd3JpdGFibGUs
IGFuZA0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93
Ij5hbjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7YmFj
a2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPiZuYnNwOyZuYnNwOyBpbmFwcHJv
cHJpYXRlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+DQogdXNlIG9mIHRoZW0gbWF5IGFkdmVyc2VseSBpbXBhY3QgYSBzeW5jaHJv
bml6YXRpb24gbmV0d29yaywgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNv
LWhpZ2hsaWdodDp5ZWxsb3ciPmZvciBleGFtcGxlLCBsb3NzIG9mIHN5bmNocm9uaXphdGlvbiBv
biBhIGNsb2NrLCBhY2N1cmFjeSBkZWdyYWRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7YmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5
ZWxsb3ciPiZuYnNwOyZuYnNwOyBvbiBhIHNldCBvZiBjbG9ja3MsIG9yIGV2ZW4gYnJlYWsgZG93
biBvZiBhIHdob2xlIHN5bmNocm9uaXphdGlvbiBuZXR3b3JrLjwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgQXJlIHlvdSBPSyB3aXRoIHRoZSBhYm92
ZSB0ZXh0cz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgYSBs
b3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZdWFubG9uZzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg
MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBudHAgW21haWx0bzpu
dHAtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGFsIE1penJhaGk8YnI+
DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTcgMjo1OSBQTTxicj4NCjxi
PlRvOjwvYj4gS2FyZW4gTydEb25vZ2h1ZTxicj4NCjxiPkNjOjwvYj4gbnRwQGlldGYub3JnOyB0
aWN0b2NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOdHBdIFtUSUNUT0NdIFdH
TEMgZm9yIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij5JIGJlbGlldmUgdGhpcyBkcmFmdCBpcyBhbG1vc3QgcmVhZHkgdG8gcHJvY2VlZCB0byB0aGUg
SUVTRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk90
aGVyIHRoYW4gdGhlIFlBTkcgZm9ybWF0IGlzc3VlcyB0aGF0IGhhdmUgYWxyZWFkeSBtZW50aW9u
ZWQgb24gdGhlIGxpc3QsIEkgYmVsaWV2ZSB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2Vj
dGlvbiBzaG91bGQgYmUgc2xpZ2h0bHkgZXh0ZW5kZWQuJm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPi0gJnF1b3Q7U29tZSBkYXRhIG5vZGVzIGRlZmluZWQgaW4gdGhpcyBZQU5HIG1vZHVsZSBh
cmUgd3JpdGFibGUsIGFuZCBhbnkgY2hhbmdlcyB0byB0aGVtIG1heSBhZHZlcnNlbHkgaW1wYWN0
IGEgc3luY2hyb25pemF0aW9uIG5ldHdvcmsuJnF1b3Q7PGJyPg0KJm5ic3A7IFBsZWFzZSBlbGFi
b3JhdGUgYWJvdXQgdGhlIGNvbnNlcXVlbmNlcywgaS5lLiwgd2hhdCBpcyB0aGUgaW1wYWN0IG9u
IHRoZSBuZXR3b3JrIChDbG9jayBpbmFjY3VyYWN5PyBMb3NzIG9mIHN5bmNocm9uaXphdGlvbj8g
T3RoZXIgY29uc2VxdWVuY2VzPykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gVGhlIHNlY3Rpb24g
c2hvdWxkIHByb2JhYmx5IG1lbnRpb24gdGhhdCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg
b2YgdGltZSBwcm90b2NvbHMgaW4gZ2VuZXJhbCBhcmUgZGlzY3Vzc2VkIGluIFtSRkMgNzM4NF0u
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaGVlcnMs
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIFNl
cCAxMywgMjAxNyBhdCAxMDoxNiBQTSwgS2FyZW4gTydEb25vZ2h1ZSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9kb25vZ2h1ZUBpc29jLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9kb25vZ2h1ZUBpc29jLm9y
ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gb2xrcyw8YnI+DQo8YnI+DQpUaGlzIG1lc3NhZ2UgYmVn
aW5zIGEgMiB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIChXR0xDKSBmb3IgdGhlIGZvbGxv
d2luZyBkb2N1bWVudDo8YnI+DQo8YnI+DQpZQU5HIERhdGEgTW9kZWwgZm9yIElFRUUgMTU4OHYy
PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0
Zi10aWN0b2MtMTU4OHYyLXlhbmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcvPC9hPjxicj4NCjxi
cj4NClBsZWFzZSByZXZpZXcgdGhlIHJlZmVyZW5jZWQgZG9jdW1lbnQgYW5kIHNlbmQgYW55IGNv
bW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgaW5jbHVkaW5nIHlvdXIgYXNzZXNzbWVudCBvZiB3
aGV0aGVyIHRoaXMgZG9jdW1lbnQgaXMgbWF0dXJlIGVub3VnaCB0byBwcm9jZWVkIHRvIHRoZSBJ
RVNHLiBQbGVhc2Ugbm90ZSB0aGF0IHRoZXNlIG1lc3NhZ2VzIG9mIHN1cHBvcnQgZm9yIHByb2dy
ZXNzaW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QgYXJlIGltcG9ydGFudA0KIGFuZCB3aWxsIGJlIHVz
ZWQgdG8gZGV0ZXJtaW5lIFdHIGNvbnNlbnN1cyB0byBwcm9jZWVkLjxicj4NCjxicj4NClBsZWFz
ZSBzZW5kIGFsbCBjb21tZW50cyBpbiBieSBUaHVyc2RheSAyOCBTZXB0ZW1iZXIgMjAxNy48YnI+
DQo8YnI+DQpUaGFuayB5b3UhPGJyPg0KS2FyZW48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRJQ1RPQyBtYWlsaW5nIGxpc3Q8YnI+DQo8
YSBocmVmPSJtYWlsdG86VElDVE9DQGlldGYub3JnIj5USUNUT0NAaWV0Zi5vcmc8L2E+PGJyPg0K
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aWN0b2MiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpY3Rv
YzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C1335dggeml507mbxchi_--


From nobody Mon Sep 18 23:52:52 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 7774F1342D3 for ; Mon, 18 Sep 2017 23:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7zEA_CWDyOjJ for ; Mon, 18 Sep 2017 23:52:48 -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 214CA133023 for ; Mon, 18 Sep 2017 23:52:47 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 451BD5CDF0 for ; Tue, 19 Sep 2017 08:52:46 +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 E51D45DD8B for ; Tue, 19 Sep 2017 08:52:45 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 19 Sep 2017 08:52:45 +0200
Message-Id: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Tue, 19 Sep 2017 08:52:43 +0200
From: "Ulrich Windl" 
To: "ntp@ietf.org" ,
References: 
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:  draft-ietf-ntp-mode-6-cmds : Issue 1
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, 19 Sep 2017 06:52:50 -0000

>>> Brian Haberman  schrieb am 18.09.2017 um =
19:10 in
Nachricht :
> Ulrich noted that this document does not specify a version number for
> the mode 6 commands. I had suggested specifying it as "version 4 (or
> earlier)" given that the introduction of mode 6 commands has occurred at
> various versions of the protocol starting at RFC 1305. Ulrich pointed
> out that the version number drives the interpretation of the status =
words.
>=20
> For people who have implemented or use mode 6 commands, what makes sense
> here? Do we need to specify a version number per mode 6 command?

Hi!

I think there are several issues:

1) Assuming there are different versions (there are!), how can one find =
out which version the server implements? See 2)

2) if a client requests a version different from the server, what should =
the server do? The server could respond with a different version number, =
indicating that it is not willing to respond / privide the information in =
the format requested. Or the server could respond with a "bad request" =
status. Finally the server could respond in the format requested... I have =
slight favor for the first variant unless there is a command to find out =
what message format versions the server can provide.

3) As it seems to be now, the server ignores the version (versions 2, 3, =
and 4 all seem to work)

Regards,
Ulrich




From nobody Tue Sep 19 00:03:13 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 C6DCD126DFE for ; Tue, 19 Sep 2017 00:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KpavnQIPGQlD for ; Tue, 19 Sep 2017 00:03:07 -0700 (PDT)
Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4650D126B6E for ; Tue, 19 Sep 2017 00:03:06 -0700 (PDT)
Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 701E4796C7 for ; Tue, 19 Sep 2017 09:03:05 +0200 (CEST)
Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 26161796A3 for ; Tue, 19 Sep 2017 09:03:04 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 19 Sep 2017 09:03:04 +0200
Message-Id: <59C0C126020000A100027F24@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Tue, 19 Sep 2017 09:03:02 +0200
From: "Ulrich Windl" 
To: "ntp@ietf.org" ,, 
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net> <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>
In-Reply-To: <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>
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:  draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 07:03:12 -0000

>>> Greg Dowd  schrieb am 18.09.2017 um 19:35 in =
Nachricht
<8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>:
> As a user, I don't have much value to add.  Our typical use case, which =
is=20
> probably pretty widespread, is via loopback interface so version isn't =
much=20
> of an issue.

Hi!

I wrote a utility that collects the performance data of our servers to =
provide some RRD graphs on a central server. One could configure the =
version for every server, of course, but naturally when upgrading, you =
easily forget to adjust the config elsewhere. Actually all of our HP-UX =
NTPv3 servers are gone now, but the tool knew how to handle them.

>From a "monlist" point of view, we still have a lot of NTPv3 clients, and =
once NTPv5 arrives, the issue will pop up again. I'm quite sure that NTPv5 =
will have some incompatibilities ;-)

Regards,
Ulrich

>=20
> Thanks...Greg
>=20
>=20
> -----Original Message-----
> From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Brian Haberman
> Sent: Monday, September 18, 2017 10:14 AM
> To: ntp@ietf.org=20
> Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
>=20
> EXTERNAL EMAIL
>=20
>=20
> Ulrich noted that there is currently no easy way to discover the version =
of=20
> the NTP server being interrogated with mode 6 commands.
>=20
> For people who have implemented or use mode 6 commands, do we want to=20
> specify a mode 6 command that determines the version of the server =
being=20
> queried?
>=20
> Regards,
> Brian
>=20
>=20
>=20
> _______________________________________________
> ntp mailing list
> ntp@ietf.org=20
> https://www.ietf.org/mailman/listinfo/ntp=20





From nobody Tue Sep 19 00:26: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 35079132F8F for ; Tue, 19 Sep 2017 00:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JsVbAD3Y27VU for ; Tue, 19 Sep 2017 00:26:33 -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 5A0A2126DFE for ; Tue, 19 Sep 2017 00:26:33 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CE12F5CEA7 for ; Tue, 19 Sep 2017 09:26:31 +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 A709B5B3F5 for ; Tue, 19 Sep 2017 09:26:31 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 19 Sep 2017 09:26:31 +0200
Message-Id: <59C0C6A4020000A100027F38@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Tue, 19 Sep 2017 09:26:28 +0200
From: "Ulrich Windl" 
To: 
Cc: "ntp@ietf.org" 
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net> <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net> 
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:  draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 07:26:35 -0000

>>> Harlan Stenn  schrieb am 19.09.2017 um 01:32 in =
Nachricht
:
> The protocol version is in the NTP header.  Granted, a V4 server can
> issue V3 queries.

Hi Harlan,

it seems you live in a simple world: Considering this tcpdump, what =
version of NTP mode 6 responses is the server sending?:
09:22:17.178611 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=3D0, =
VN=3D3, Mode=3D6, length=3D20
09:22:17.178842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=3D0, =
VN=3D3, Mode=3D6, length=3D80
09:22:17.179593 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=3D0, =
VN=3D4, Mode=3D6, length=3D12
09:22:17.179842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=3D0, =
VN=3D4, Mode=3D6, length=3D52

I have the suspect that the server just copies the version from the =
request to the response. As Brian pointed out some bits have a different =
meaning between NTPv3 and NTPv4, but this way you never find out what bits =
the server is really sending.

Regards,
Ulrich



>=20
> As for anything else:
>=20
> - some will consider this sensitive information that should only be
>   disclosed to authorized parties.
>=20
> - we use: ntpq -c "rv 0 daemon_version"
>   to query the daemon version.  There is no Standard way to get this
>   information, and I'm open to an INFORMATIONAL list of system variables
>   that folks might find interesting and/or useful.
>=20
> H
> --
>=20
> On 9/18/2017 10:35 AM, Greg Dowd wrote:
>> As a user, I don't have much value to add.  Our typical use case, which =
is=20
> probably pretty widespread, is via loopback interface so version isn't =
much=20
> of an issue.
>>=20
>> Thanks...Greg
>>=20
>>=20
>> -----Original Message-----
>> From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Brian Haberman
>> Sent: Monday, September 18, 2017 10:14 AM
>> To: ntp@ietf.org=20
>> Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
>>=20
>> EXTERNAL EMAIL
>>=20
>>=20
>> Ulrich noted that there is currently no easy way to discover the =
version of=20
> the NTP server being interrogated with mode 6 commands.
>>=20
>> For people who have implemented or use mode 6 commands, do we want =
to=20
> specify a mode 6 command that determines the version of the server =
being=20
> queried?
>>=20
>> Regards,
>> Brian
>>=20
>>=20
>>=20
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/ntp=20
>>=20
>=20
> --=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 Tue Sep 19 00:39:50 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 E772713208E for ; Tue, 19 Sep 2017 00:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qjg2HTolcy3k for ; Tue, 19 Sep 2017 00:39:47 -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 130FD126DFE for ; Tue, 19 Sep 2017 00:39:47 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9BF0C5DCC6 for ; Tue, 19 Sep 2017 09:39:45 +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 385A55DD05 for ; Tue, 19 Sep 2017 09:39:44 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 19 Sep 2017 09:39:44 +0200
Message-Id: <59C0C9BD020000A100027F3D@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Tue, 19 Sep 2017 09:39:41 +0200
From: "Ulrich Windl" 
To: "ntp@ietf.org" ,
References:  
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:  draft-ietf-ntp-mode-6-cmds : Issue 1
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, 19 Sep 2017 07:39:49 -0000

>>> Harlan Stenn  schrieb am 19.09.2017 um 01:36 in =
Nachricht
:

>=20
> On 9/18/2017 10:10 AM, Brian Haberman wrote:
>> Ulrich noted that this document does not specify a version number for
>> the mode 6 commands. I had suggested specifying it as "version 4 (or
>> earlier)" given that the introduction of mode 6 commands has occurred =
at
>> various versions of the protocol starting at RFC 1305. Ulrich pointed
>> out that the version number drives the interpretation of the status =
words.
>>=20
>> For people who have implemented or use mode 6 commands, what makes =
sense
>> here? Do we need to specify a version number per mode 6 command?
>=20
> I've long wanted a way to identify more information about information
> about what information is available via mode6 commands, and the format
> of that information.
>=20
> While some of this information is part of the "core", a lot of it is
> implementation-specific, and can easily change from one code version to
> the next.

Hi!

"It can", but should it? If you are writing software for yourself, you are =
free to change it all the time. But if you implement some standard, either =
stick to the standard, or define a new standard. Arguing that this part is =
not in the standard does not help anyone. As a matter of fact NTPv3 and =
NTPv4 return different information for the exactly same command. Obviously =
that was an oversight when changing things, but that should not repeat, =
and, if possible, also clean up the past (i.e.: provide a mechanism to get =
well-specified responses).

>=20
> I don't think we want to cast any of this into concrete.

This kind of flexibility on your side causes confusion on the other side.
Let me quote some of my Perl code again (trying to get version independent =
NTP performance gauges):

        if (!$NTPv4) {
            $vars->set_variable('frequency', $vars->variable('freq') / =
1000);
            $vars->set_variable('offset', $vars->variable('phase'));
            $vars->set_variable('noise', $vars->variable('error'));
            $vars->set_variable('jitter', 0);
            $vars->set_variable('stability', '0');
        } else {            # ntpd 4.2.6p2 "introduces" "new" variables
            $vars->copy_variable('rootdispersion', 'rootdisp');
            $vars->copy_variable('noise', 'clk_jitter');
            $vars->copy_variable('jitter', 'sys_jitter');
            $vars->copy_variable('stability', 'clk_wander');
            $vars->copy_variable('poll', 'tc');
            # ntpd 4.2.8 also has new variables
            # "clk_jitter" (CS_ERROR),
            # "ctr_frequency" (Windows: Performance Counter Drift)
        }

So it's hard to get one set of well-defined variables. Don't make it =
worse!

>=20
> On the other hand, we do need a way to figure out what's available
> (which may changed based on authorization levels) and the format in
> which it's presented.

Absolutely!

Regards,
Ulrich

>=20
> --=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 Tue Sep 19 01:24:20 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 9EBAC1342C9 for ; Tue, 19 Sep 2017 01:24:18 -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 rQEF2b_5X9wA for ; Tue, 19 Sep 2017 01:24:17 -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 297F51342C8 for ; Tue, 19 Sep 2017 01:24:17 -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 BE35DB87C; Tue, 19 Sep 2017 08:24:16 +0000 (UTC)
To: Ulrich Windl 
Cc: "ntp@ietf.org" 
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net> <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>  <59C0C6A4020000A100027F38@gwsmtp1.uni-regensburg.de>
From: Harlan Stenn 
Message-ID: <82786eed-ec09-7f0c-730d-3f767651f5fa@nwtime.org>
Date: Tue, 19 Sep 2017 01:24:16 -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: <59C0C6A4020000A100027F38@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:  draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 08:24:19 -0000

On 9/19/17 12:26 AM, Ulrich Windl wrote:
>>>> Harlan Stenn  schrieb am 19.09.2017 um 01:32 in Nachricht
> :
>> The protocol version is in the NTP header.  Granted, a V4 server can
>> issue V3 queries.
> 
> Hi Harlan,
> 
> it seems you live in a simple world: Considering this tcpdump, what version of NTP mode 6 responses is the server sending?:
> 09:22:17.178611 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=0, VN=3, Mode=6, length=20
> 09:22:17.178842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=0, VN=3, Mode=6, length=80
> 09:22:17.179593 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=0, VN=4, Mode=6, length=12
> 09:22:17.179842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=0, VN=4, Mode=6, length=52
> 
> I have the suspect that the server just copies the version from the request to the response. As Brian pointed out some bits have a different meaning between NTPv3 and NTPv4, but this way you never find out what bits the server is really sending.

The word "version" is the issue there.

You don't mean "core protocol version", you want to know something else.

You *might* mean "what version of ntp software are you running?"

You might mean "what ntpq mode 6 protocol version are you running?"

For the last part, there are some "generally useful" values, and a
larger number of implementation-specific values.

The implementation-specific values can, and arguably should change from
time to time.

We've had a number of these changes over the years, mostly because
definitions have changed.  How far do you want to go with this?  Look at
bug 3067 for example - we've changed the value of root distance at least
twice over the years.

The refid was an IPv4 address for S2+ for a long time.  Then we started
using a hash for an IPv6 refid, and it became clear that it sometimes
caused problems.  Now we're looking at the NOT-YOU refid
(127.127.127.127), the SUGGEST-REFID option, and the IPv6 refid, which
is the previous hash except the first octet is set to 255.

In the reference implementation, to avoid perpetuating the fallacy that
a refid is "expected" to be in the IPv4 format, we have had the 'apeers'
command, which shows the association number in addition to the other
information, and makes room for this by displaying the refid as 8 hex
digits.

I'm interested in seeing what you propose to fix this - what some will
perceive as mandating consistency, others will see as perpetuating
broken behavior and limiting innovation.

H
--
> Regards,
> Ulrich
> 
> 
> 
>>
>> As for anything else:
>>
>> - some will consider this sensitive information that should only be
>>   disclosed to authorized parties.
>>
>> - we use: ntpq -c "rv 0 daemon_version"
>>   to query the daemon version.  There is no Standard way to get this
>>   information, and I'm open to an INFORMATIONAL list of system variables
>>   that folks might find interesting and/or useful.
>>
>> H
>> --
>>
>> On 9/18/2017 10:35 AM, Greg Dowd wrote:
>>> As a user, I don't have much value to add.  Our typical use case, which is 
>> probably pretty widespread, is via loopback interface so version isn't much 
>> of an issue.
>>>
>>> Thanks...Greg
>>>
>>>
>>> -----Original Message-----
>>> From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Brian Haberman
>>> Sent: Monday, September 18, 2017 10:14 AM
>>> To: ntp@ietf.org 
>>> Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
>>>
>>> EXTERNAL EMAIL
>>>
>>>
>>> Ulrich noted that there is currently no easy way to discover the version of 
>> the NTP server being interrogated with mode 6 commands.
>>>
>>> For people who have implemented or use mode 6 commands, do we want to 
>> specify a mode 6 command that determines the version of the server being 
>> queried?
>>>
>>> Regards,
>>> Brian
>>>
>>>
>>>
>>> _______________________________________________
>>> ntp mailing list
>>> ntp@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/ntp 
>>>
>>
>> -- 
>> 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 
http://networktimefoundation.org - be a member!


From nobody Tue Sep 19 01:27:49 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 4B7BB132198 for ; Tue, 19 Sep 2017 01:27:48 -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 MDC1TZMQbVAy for ; Tue, 19 Sep 2017 01:27:47 -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 0D9A413207A for ; Tue, 19 Sep 2017 01:27:47 -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 B953FB87C; Tue, 19 Sep 2017 08:27:46 +0000 (UTC)
To: Ulrich Windl 
Cc: "ntp@ietf.org" 
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net> <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>  <59C0C6A4020000A100027F38@gwsmtp1.uni-regensburg.de>
From: Harlan Stenn 
Message-ID: <0fb32f79-cf90-8dbc-b930-babd14466c26@nwtime.org>
Date: Tue, 19 Sep 2017 01:27: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: <59C0C6A4020000A100027F38@gwsmtp1.uni-regensburg.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Ntp] Antw: Re:  draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 08:27:48 -0000

Oh, one more thing:

On 9/19/17 12:26 AM, Ulrich Windl wrote:
>>>> Harlan Stenn  schrieb am 19.09.2017 um 01:32 in Nachricht
> :
>> The protocol version is in the NTP header.  Granted, a V4 server can
>> issue V3 queries.
> 
> Hi Harlan,
> 
> it seems you live in a simple world: Considering this tcpdump, what version of NTP mode 6 responses is the server sending?:
> 09:22:17.178611 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=0, VN=3, Mode=6, length=20
> 09:22:17.178842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=0, VN=3, Mode=6, length=80
> 09:22:17.179593 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=0, VN=4, Mode=6, length=12
> 09:22:17.179842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=0, VN=4, Mode=6, length=52
> 
> I have the suspect that the server just copies the version from the request to the response. As Brian pointed out some bits have a different meaning between NTPv3 and NTPv4, but this way you never find out what bits the server is really sending.

Yes, this is a problem that we have never addressed.

Should a v4 server that gets a v3 query send back "legacy" v3
information, or the updated v4 information?

There are good reasons for each choice, and please remember that by
asking a v4 server to send back a v[1-3] response you're asking for a
lot of extra code, and that baggage will grow and grow...

H
--
> Regards,
> Ulrich
> 
> 
> 
>>
>> As for anything else:
>>
>> - some will consider this sensitive information that should only be
>>   disclosed to authorized parties.
>>
>> - we use: ntpq -c "rv 0 daemon_version"
>>   to query the daemon version.  There is no Standard way to get this
>>   information, and I'm open to an INFORMATIONAL list of system variables
>>   that folks might find interesting and/or useful.
>>
>> H
>> --
>>
>> On 9/18/2017 10:35 AM, Greg Dowd wrote:
>>> As a user, I don't have much value to add.  Our typical use case, which is 
>> probably pretty widespread, is via loopback interface so version isn't much 
>> of an issue.
>>>
>>> Thanks...Greg
>>>
>>>
>>> -----Original Message-----
>>> From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Brian Haberman
>>> Sent: Monday, September 18, 2017 10:14 AM
>>> To: ntp@ietf.org 
>>> Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
>>>
>>> EXTERNAL EMAIL
>>>
>>>
>>> Ulrich noted that there is currently no easy way to discover the version of 
>> the NTP server being interrogated with mode 6 commands.
>>>
>>> For people who have implemented or use mode 6 commands, do we want to 
>> specify a mode 6 command that determines the version of the server being 
>> queried?
>>>
>>> Regards,
>>> Brian
>>>
>>>
>>>
>>> _______________________________________________
>>> ntp mailing list
>>> ntp@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/ntp 
>>>
>>
>> -- 
>> 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 
http://networktimefoundation.org - be a member!


From nobody Tue Sep 19 01:55:00 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 0B84A1342E1 for ; Tue, 19 Sep 2017 01:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZZlz3buq4H1b for ; Tue, 19 Sep 2017 01:54:56 -0700 (PDT)
Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DCC126B6E for ; Tue, 19 Sep 2017 01:54:56 -0700 (PDT)
Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 87649795D2 for ; Tue, 19 Sep 2017 10:54:54 +0200 (CEST)
Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 4D42979580 for ; Tue, 19 Sep 2017 10:54:53 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 19 Sep 2017 10:54:53 +0200
Message-Id: <59C0DB5B020000A100027F4C@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Tue, 19 Sep 2017 10:54:51 +0200
From: "Ulrich Windl" 
To: 
Cc: "ntp@ietf.org" 
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net> <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>  <59C0C6A4020000A100027F38@gwsmtp1.uni-regensburg.de> <82786eed-ec09-7f0c-730d-3f767651f5fa@nwtime.org>
In-Reply-To: <82786eed-ec09-7f0c-730d-3f767651f5fa@nwtime.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: 
Subject: Re: [Ntp] Antw: Re:  draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 08:54:58 -0000

>>> Harlan Stenn  schrieb am 19.09.2017 um 10:24 in =
Nachricht
<82786eed-ec09-7f0c-730d-3f767651f5fa@nwtime.org>:

>=20
> On 9/19/17 12:26 AM, Ulrich Windl wrote:
>>>>> Harlan Stenn  schrieb am 19.09.2017 um 01:32 in =
Nachricht
>> :
>>> The protocol version is in the NTP header.  Granted, a V4 server can
>>> issue V3 queries.
>>=20
>> Hi Harlan,
>>=20
>> it seems you live in a simple world: Considering this tcpdump, what =
version=20
> of NTP mode 6 responses is the server sending?:
>> 09:22:17.178611 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=3D0, =
VN=3D3,=20
> Mode=3D6, length=3D20
>> 09:22:17.178842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=3D0, =
VN=3D3,=20
> Mode=3D6, length=3D80
>> 09:22:17.179593 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=3D0, =
VN=3D4,=20
> Mode=3D6, length=3D12
>> 09:22:17.179842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=3D0, =
VN=3D4,=20
> Mode=3D6, length=3D52
>>=20
>> I have the suspect that the server just copies the version from the =
request=20
> to the response. As Brian pointed out some bits have a different =
meaning=20
> between NTPv3 and NTPv4, but this way you never find out what bits the =
server=20
> is really sending.
>=20
> The word "version" is the issue there.
>=20
> You don't mean "core protocol version", you want to know something else.

Hi Harlan,

as the control message format if different from the time format, it's not =
obvious that VN still has the same meaning. You think it's referring to =
the "core protocol version" without saying what that is (time messages?).

>=20
> You *might* mean "what version of ntp software are you running?"

The version of software is some vendor string, where you MAY be able to =
deduce the NTP core version from.

>=20
> You might mean "what ntpq mode 6 protocol version are you running?"

My guess was that NTPv3 support VN=3D=3D3, and NTPv4 supports VN=3D=3D4 =
(and maybe VN=3D=3D3 for compatibility with old clients).

>=20
> For the last part, there are some "generally useful" values, and a
> larger number of implementation-specific values.
>=20
> The implementation-specific values can, and arguably should change from
> time to time.

why _should_ they change? It sound like a recommendation.

>=20
> We've had a number of these changes over the years, mostly because
> definitions have changed.  How far do you want to go with this?  Look at
> bug 3067 for example - we've changed the value of root distance at least
> twice over the years.
>=20
> The refid was an IPv4 address for S2+ for a long time.  Then we started

It was "_interpreted as_ an IPv4 address while the implementation used an =
IPv4 address, and one could deduce the server from it. The problem was to =
use and advertise the rfid as IPv4 address. That's overspecifying an ID.

> using a hash for an IPv6 refid, and it became clear that it sometimes
> caused problems.  Now we're looking at the NOT-YOU refid
> (127.127.127.127), the SUGGEST-REFID option, and the IPv6 refid, which
> is the previous hash except the first octet is set to 255.
>=20
> In the reference implementation, to avoid perpetuating the fallacy that
> a refid is "expected" to be in the IPv4 format, we have had the 'apeers'
> command, which shows the association number in addition to the other
> information, and makes room for this by displaying the refid as 8 hex
> digits.
>=20
> I'm interested in seeing what you propose to fix this - what some will
> perceive as mandating consistency, others will see as perpetuating
> broken behavior and limiting innovation.

Use a V3 ntpq to query a V4 server: The status interpretation may be =
wrong.
Use a V4 ntpq to query a V3 server: The status interpretation may be =
wrong.

You think it's all right, and no need to fix things? I don't agree. =
Several things were messed up in the past, but that shouldn't be the =
strategy for the future.

Regards,
Ulrich
>=20
> H
> --
>> Regards,
>> Ulrich
>>=20
>>=20
>>=20
>>>
>>> As for anything else:
>>>
>>> - some will consider this sensitive information that should only be
>>>   disclosed to authorized parties.
>>>
>>> - we use: ntpq -c "rv 0 daemon_version"
>>>   to query the daemon version.  There is no Standard way to get this
>>>   information, and I'm open to an INFORMATIONAL list of system =
variables
>>>   that folks might find interesting and/or useful.
>>>
>>> H
>>> --
>>>
>>> On 9/18/2017 10:35 AM, Greg Dowd wrote:
>>>> As a user, I don't have much value to add.  Our typical use case, =
which is=20
>>> probably pretty widespread, is via loopback interface so version isn't =
much=20
>>> of an issue.
>>>>
>>>> Thanks...Greg
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: ntp [mailto:ntp-bounces@ietf.org] On Behalf Of Brian Haberman
>>>> Sent: Monday, September 18, 2017 10:14 AM
>>>> To: ntp@ietf.org=20
>>>> Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2
>>>>
>>>> EXTERNAL EMAIL
>>>>
>>>>
>>>> Ulrich noted that there is currently no easy way to discover the =
version of=20
>>> the NTP server being interrogated with mode 6 commands.
>>>>
>>>> For people who have implemented or use mode 6 commands, do we want =
to=20
>>> specify a mode 6 command that determines the version of the server =
being=20
>>> queried?
>>>>
>>>> Regards,
>>>> Brian
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ntp mailing list
>>>> ntp@ietf.org=20
>>>> https://www.ietf.org/mailman/listinfo/ntp=20
>>>>
>>>
>>> --=20
>>> Harlan Stenn, Network Time Foundation
>>> http://nwtime.org - be a Member!
>>>
>>> _______________________________________________
>>> ntp mailing list
>>> ntp@ietf.org=20
>>> https://www.ietf.org/mailman/listinfo/ntp=20
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
> --=20
> Harlan Stenn 
> http://networktimefoundation.org - be a member!




From nobody Tue Sep 19 02:25:29 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 5C977126DFE; Thu, 14 Sep 2017 13:57:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: ntp@ietf.org, tictoc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.61.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150542263531.18861.10375485091254280521@ietfa.amsl.com>
Date: Thu, 14 Sep 2017 13:57:15 -0700
Archived-At: 
X-Mailman-Approved-At: Tue, 19 Sep 2017 02:25:27 -0700
Subject: [Ntp] Network Time Protocol (ntp) WG Virtual Meeting: 2017-09-29
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, 14 Sep 2017 20:57:15 -0000

The Network Time Protocol (ntp) and Timing over IP Connection and 
Transfer of Clock (tictoc) Working Groups will hold a joint virtual 
interim meeting on 2017-09-29 from 15:30 to 17:00 UTC.

Agenda:
1. WGLC comment resolution and way forward for MAC update for NTP
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

2. WGLC comment resolution and way forward for NTS for NTP
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

3. NTP Extension fields
https://datatracker.ietf.org/doc/draft-stenn-ntp-extension-fields/

4. NTP Control messages
https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/

5. NTP Data minimization
https://datatracker.ietf.org/doc/draft-ietf-ntp-data-minimization/

6. WGLC for YANG Data Model for IEEE 1588v2
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

7. IEEE 1588 Enterprise Profile
https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/

8. Not on the agenda today but not forgotten
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/
https://datatracker.ietf.org/doc/draft-ietf-ntp-yang-data-model/

9. AOB

Information about remote participation:

Topic: IETF NTP/TICTOC virtual interim meeting
Time: Sep 29, 2017 11:30 AM Eastern Standard Time (US and Canada)

Join from PC, Mac, Linux, iOS or Android: https://isoc.zoom.us/j/801443999

Or iPhone one-tap :
US: +16465588656,,801443999# or +16699006833,,801443999#
Or Telephone：
Dial(for higher quality, dial a number based on your current location)：
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 801 443 999
International numbers available: https://isoc.zoom.us/zoomconference?m=2VfBY-IRsneP459hjV21v7Mo2WyW2grJ

Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
Meeting ID: 801 443 999

SIP: 801443999@zoomcrc.com


From nobody Tue Sep 19 02:25:35 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 AB8C5133071; Mon, 18 Sep 2017 10:02:15 -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.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150575413564.15695.207605755001488178@ietfa.amsl.com>
Date: Mon, 18 Sep 2017 10:02:15 -0700
Archived-At: 
X-Mailman-Approved-At: Tue, 19 Sep 2017 02:25:27 -0700
Subject: [Ntp] I-D Action: draft-ietf-ntp-mode-6-cmds-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, 18 Sep 2017 17:02:16 -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           : Control Messages Protocol for Use with Network Time Protocol Version 4
        Authors         : David L. Mills
                          Brian Haberman
	Filename        : draft-ietf-ntp-mode-6-cmds-03.txt
	Pages           : 21
	Date            : 2017-09-18

Abstract:
   This document describes the structure of the control messages used
   with the Network Time Protocol.  These control messages can be used
   to monitor and control the Network Time Protocol application running
   on any IP network attached computer.  The information in this
   document was originally described in Appendix B of RFC 1305.  The
   goal of this document is to provide a historic description of the
   control messages.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-03
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mode-6-cmds-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-mode-6-cmds-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 Sep 19 02:25:42 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 2DFDB132D41; Tue, 19 Sep 2017 02:02:36 -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, kodonog@pobox.com, ntp@ietf.org, suresh.krishnan@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150581175614.11704.5581566297615187178.idtracker@ietfa.amsl.com>
Date: Tue, 19 Sep 2017 02:02:36 -0700
Archived-At: 
X-Mailman-Approved-At: Tue, 19 Sep 2017 02:25:27 -0700
Subject: [Ntp] ntp - New 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, 19 Sep 2017 09:02:36 -0000

A new meeting session request has just been submitted by Karen O'Donoghue, a Chair of the ntp working group.


---------------------------------------------------------
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: 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 Tue Sep 19 02:25:47 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 9BFA613208E; Tue, 19 Sep 2017 02:02:40 -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, kodonog@pobox.com, ntp@ietf.org, suresh.krishnan@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150581176063.11869.8037728567316799870.idtracker@ietfa.amsl.com>
Date: Tue, 19 Sep 2017 02:02:40 -0700
Archived-At: 
X-Mailman-Approved-At: Tue, 19 Sep 2017 02:25:27 -0700
Subject: [Ntp] ntp - New 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, 19 Sep 2017 09:02:41 -0000

A new meeting session request has just been submitted by Karen O'Donoghue, a Chair of the ntp working group.


---------------------------------------------------------
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: 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 Tue Sep 19 02:32: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 4F21C126C0F for ; Tue, 19 Sep 2017 02:32:43 -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 C-AjDYQ1vlIv for ; Tue, 19 Sep 2017 02:32:41 -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 A0CBF126BF0 for ; Tue, 19 Sep 2017 02:32:41 -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 6D19CB86A; Tue, 19 Sep 2017 09:32:41 +0000 (UTC)
To: Ulrich Windl 
Cc: "ntp@ietf.org" 
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net> <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>  <59C0C6A4020000A100027F38@gwsmtp1.uni-regensburg.de> <82786eed-ec09-7f0c-730d-3f767651f5fa@nwtime.org> <59C0DB5B020000A100027F4C@gwsmtp1.uni-regensburg.de>
From: Harlan Stenn 
Message-ID: 
Date: Tue, 19 Sep 2017 02:32:40 -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: <59C0DB5B020000A100027F4C@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:  draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 09:32:43 -0000

Hi Ulrich,

On 9/19/17 1:54 AM, Ulrich Windl wrote:
>>>> Harlan Stenn  schrieb am 19.09.2017 um 10:24 in Nachricht
> <82786eed-ec09-7f0c-730d-3f767651f5fa@nwtime.org>:
> 
>>
>> On 9/19/17 12:26 AM, Ulrich Windl wrote:
>>>>>> Harlan Stenn  schrieb am 19.09.2017 um 01:32 in Nachricht
>>> :
>>>> The protocol version is in the NTP header.  Granted, a V4 server can
>>>> issue V3 queries.
>>>
>>> Hi Harlan,
>>>
>>> it seems you live in a simple world: Considering this tcpdump, what version 
>> of NTP mode 6 responses is the server sending?:
>>> 09:22:17.178611 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=0, VN=3, 
>> Mode=6, length=20
>>> 09:22:17.178842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=0, VN=3, 
>> Mode=6, length=80
>>> 09:22:17.179593 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=0, VN=4, 
>> Mode=6, length=12
>>> 09:22:17.179842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=0, VN=4, 
>> Mode=6, length=52
>>>
>>> I have the suspect that the server just copies the version from the request 
>> to the response. As Brian pointed out some bits have a different meaning 
>> between NTPv3 and NTPv4, but this way you never find out what bits the server 
>> is really sending.
>>
>> The word "version" is the issue there.
>>
>> You don't mean "core protocol version", you want to know something else.
> 
> Hi Harlan,
> 
> as the control message format if different from the time format, it's not obvious that VN still has the same meaning. You think it's referring to the "core protocol version" without saying what that is (time messages?).
> 
>>
>> You *might* mean "what version of ntp software are you running?"
> 
> The version of software is some vendor string, where you MAY be able to deduce the NTP core version from.
> 
>>
>> You might mean "what ntpq mode 6 protocol version are you running?"
> 
> My guess was that NTPv3 support VN==3, and NTPv4 supports VN==4 (and maybe VN==3 for compatibility with old clients).

This again may mean many things.  It's one thing to know that the
protocol mode 6 "command" structure is supported.  It's another thing to
know what the implementation is willing to send.

>> For the last part, there are some "generally useful" values, and a
>> larger number of implementation-specific values.
>>
>> The implementation-specific values can, and arguably should change from
>> time to time.
> 
> why _should_ they change? It sound like a recommendation.

Not intended as a recommendation.

See below.

>> We've had a number of these changes over the years, mostly because
>> definitions have changed.  How far do you want to go with this?  Look at
>> bug 3067 for example - we've changed the value of root distance at least
>> twice over the years.
>>
>> The refid was an IPv4 address for S2+ for a long time.  Then we started
> 
> It was "_interpreted as_ an IPv4 address while the implementation used an IPv4 address, and one could deduce the server from it. The problem was to use and advertise the rfid as IPv4 address. That's overspecifying an ID.

So what are you trying to specify in this document?

>> using a hash for an IPv6 refid, and it became clear that it sometimes
>> caused problems.  Now we're looking at the NOT-YOU refid
>> (127.127.127.127), the SUGGEST-REFID option, and the IPv6 refid, which
>> is the previous hash except the first octet is set to 255.
>>
>> In the reference implementation, to avoid perpetuating the fallacy that
>> a refid is "expected" to be in the IPv4 format, we have had the 'apeers'
>> command, which shows the association number in addition to the other
>> information, and makes room for this by displaying the refid as 8 hex
>> digits.
>>
>> I'm interested in seeing what you propose to fix this - what some will
>> perceive as mandating consistency, others will see as perpetuating
>> broken behavior and limiting innovation.
> 
> Use a V3 ntpq to query a V4 server: The status interpretation may be wrong.
> Use a V4 ntpq to query a V3 server: The status interpretation may be wrong.
> 
> You think it's all right, and no need to fix things? I don't agree. Several things were messed up in the past, but that shouldn't be the strategy for the future.

No, I think that the situation you describe with the status
interpretation is wrong and should be addressed.  I haven't checked out
what you say, but I believe you.  But there are other things that
*should* be changed from time to time - new variables, changed
variables, etc.  We might be able to enumerate the list of core stuff
that folks MUST implement.  We can define things that implementors
SHOULD implement.  And there are many things that will be
implementation-specific, and implementors should be given free reign on
these implementation-specific items.

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!


From nobody Tue Sep 19 02:44:33 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 3993A126BF0 for ; Tue, 19 Sep 2017 02:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.033
X-Spam-Level: *
X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982] autolearn=no 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 SeSSZrtT1PgJ for ; Tue, 19 Sep 2017 02:44:31 -0700 (PDT)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 82131132EDA for ; Tue, 19 Sep 2017 02:44:31 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id CB94F40605C; Tue, 19 Sep 2017 02:44:30 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: "Ulrich Windl" 
cc: "ntp@ietf.org" , hmurray@megapathdsl.net
From: Hal Murray 
In-Reply-To: Message from "Ulrich Windl"  of "Tue, 19 Sep 2017 10:54:51 +0200." <59C0DB5B020000A100027F4C@gwsmtp1.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 19 Sep 2017 02:44:30 -0700
Message-Id: <20170919094430.CB94F40605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: 
Subject: Re: [Ntp] Antw: Re: draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 09:44:32 -0000

> why _should_ they change? It sound like a recommendation.

In this context, the version you are talking about is a major version.  There 
are also minor versions that don't show up in the protocol.  Things will 
change as new features are added or existing features are dropped.

I think that the basic functions won't change much(?) within a major version 
but minor functions will change and ntpq and friends need to be prepared for 
that.  To complicate things, the minor versions can be a tree rather than a 
line.

It might be possible to invent a meta protocol so you could ask a ntp server 
what it supports for mode 6.  I doubt if that would be worthwhile.  I could 
easily be wrong.

It might make sense to expect a ntp package to include documentation for what 
it supports for mode 6.


-- 
These are my opinions.  I hate spam.




From nobody Tue Sep 19 05:36:59 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 349B1134233 for ; Tue, 19 Sep 2017 05:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tHd3EsOTSGDY for ; Tue, 19 Sep 2017 05:36:56 -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 3572713428F for ; Tue, 19 Sep 2017 05:36:48 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A36D25CFD2 for ; Tue, 19 Sep 2017 14:36:46 +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 55CF95B215 for ; Tue, 19 Sep 2017 14:36:45 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 19 Sep 2017 14:36:45 +0200
Message-Id: <59C10F5B020000A100027F6D@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Tue, 19 Sep 2017 14:36:43 +0200
From: "Ulrich Windl" 
To: 
Cc: "ntp@ietf.org" 
References: <28648a97-f9d2-3189-3ec3-5f441747d09f@innovationslab.net> <8D2BF679AAC7C346848A489074F9F8BFD283E391@sjsrvexchmbx1.microsemi.net>  <59C0C6A4020000A100027F38@gwsmtp1.uni-regensburg.de> <82786eed-ec09-7f0c-730d-3f767651f5fa@nwtime.org> <59C0DB5B020000A100027F4C@gwsmtp1.uni-regensburg.de> 
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:  Antw: Re:  draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 12:36:58 -0000

>>> Harlan Stenn  schrieb am 19.09.2017 um 11:32 in =
Nachricht
:

[...]
>>> The refid was an IPv4 address for S2+ for a long time.  Then we =
started
>>=20
>> It was "_interpreted as_ an IPv4 address while the implementation used =
an=20
> IPv4 address, and one could deduce the server from it. The problem was =
to use=20
> and advertise the rfid as IPv4 address. That's overspecifying an ID.
>=20
> So what are you trying to specify in this document?

"An ID is a 32 bit value that is identical iff the servers are identical."
No more, no less. You could say an ID COULD be derived from the FQHN (for =
example).

[...]

Regards,
Ulrich




From nobody Tue Sep 19 05:54:59 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 241EF13428A for ; Tue, 19 Sep 2017 05:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GEYT3o1-wTXh for ; Tue, 19 Sep 2017 05:54:55 -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 340DD134235 for ; Tue, 19 Sep 2017 05:54:55 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 88D335CFD2 for ; Tue, 19 Sep 2017 14:54:53 +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 00ED35CF64 for ; Tue, 19 Sep 2017 14:54:52 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Tue, 19 Sep 2017 14:54:52 +0200
Message-Id: <59C1139A020000A100027F72@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Tue, 19 Sep 2017 14:54:50 +0200
From: "Ulrich Windl" 
To: "Hal Murray" 
Cc: "ntp@ietf.org" 
References: Message from "Ulrich Windl"  of "Tue, 19 Sep 2017 10:54:51 +0200." <59C0DB5B020000A100027F4C@gwsmtp1.uni-regensburg.de> <20170919094430.CB94F40605C@ip-64-139-1-69.sjc.megapath.net>
In-Reply-To: <20170919094430.CB94F40605C@ip-64-139-1-69.sjc.megapath.net>
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:  Antw: Re: draft-ietf-ntp-mode-6-cmds : Issue 2
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, 19 Sep 2017 12:54:57 -0000

>>> Hal Murray  schrieb am 19.09.2017 um 11:44 in
Nachricht <20170919094430.CB94F40605C@ip-64-139-1-69.sjc.megapath.net>:
>>  why _should_ they change? It sound like a recommendation.
>=20
> In this context, the version you are talking about is a major version. =
=20
> There=20
> are also minor versions that don't show up in the protocol.  Things =
will=20
> change as new features are added or existing features are dropped.
>=20
> I think that the basic functions won't change much(?) within a major =
version=20
>=20
> but minor functions will change and ntpq and friends need to be prepared =
for=20
>=20
> that.  To complicate things, the minor versions can be a tree rather =
than a=20
> line.
>=20
> It might be possible to invent a meta protocol so you could ask a ntp =
server=20
>=20
> what it supports for mode 6.  I doubt if that would be worthwhile.  I =
could=20
> easily be wrong.
>=20
> It might make sense to expect a ntp package to include documentation =
for=20
> what=20
> it supports for mode 6.

Hi!

There are some less-documented features like "sys_var_list" that returns =
the list of system variable names like this:
ntpq> rv 0 "sys_var_list"
sys_var_list=3D"leap,stratum,precision,rootdelay,rootdisp,refid,reftime,tc,=
peer,offset,frequency,sys_jitter,clk_jitter,clock,processor,system,version,=
clk_wander,sys_var_list,tai,leapsec,expire,mintc,mru_enabled,mru_depth,mru_=
deepest,mru_mindepth,mru_maxage,mru_maxdepth,mru_mem,mru_maxmem,ss_uptime,s=
s_reset,ss_received,ss_thisver,ss_oldver,ss_badformat,ss_badauth,ss_decline=
d,ss_restricted,ss_limited,ss_kodsent,ss_processed,peeradr,peermode,bcastde=
lay,authdelay"

But you (a program) cannot guess the meaning from the names.
Another problem is that the text format used for values is not specified =
at all: Things get interesting if you want to represent strings containing =
a comma or lists of similar values.

For example, this is how an mrulist is transferred (in three response =
packets):
        nonce=3Ddd6b9112c3bf4c4d7c00d1aa, ct.0=3D377, last.0=3D0xdd6b896b.7=
7aa8fc2,^M^
Jaddr.0=3D172.20.16.10:123, first.0=3D0xdd6516f8.771ac3a8, mv.0=3D36,^M^Jrs=
.0=3D0x188, _
W].0=3D18446744073709529092, rs.1=3D0x188, ct.1=3D374,^M^Jlast.1=3D0xdd6b8a=
33.77bfc0d6,
mv.1=3D36, addr.1=3D172.20.16.4:123,^M^Jfirst.1=3D0xdd6516f8.76df78d9, =
addr.2=3D172.20.1
6.6:123,^M^Jlast.2=3D0xdd6b8f4f.7781c282, first.2=3D0xdd6516f8.76e30e5f, =
ct.2=3D367,^M
^Jmv.2=3D36, rs.2=3D0x188, ct.3=3D373, first.3=3D0xdd6516f8.77d02e9e,^M^Jad=
dr.3=3D172.20.1
6.1:123, mv.3=3D36, last.3=3D0xdd6b8f82.778bcf2a, rs.3=3D0x188,^M^Jlast.4=
=3D0xdd6b8fd7.778
592d1, first.4=3D0xdd6516f8.76e3dc21, rs.4=3D0x188,^M^Jct.4=3D377, =
mv.4=3D36, addr.4=3D172
.20.16.5:123, last.5=3D0xdd6b903b.7774c6c9,^M^Jfirst.5=3D0xdd6516f8.76e1c05=
3, ct.5=3D3
71, addr.5=3D172.20.16.3:123, mv.5=3D36,^M^Jrs.5=3D0x188, ct.6=3D373, =
last.6=3D0xdd6b90b2.
7784ee72, mv.6=3D36,^M^Jfirst.6=3D0xdd6516f8.77bbd81f, rs.6=3D0x188, =
addr.6=3D172.20.16.
2:123,^M^Jlast.7=3D0xdd6b90ee.777b2c6e, first.7=3D0xdd6516f8.76e45fae, =
ct.7=3D375,^M^J
addr.7=3D172.20.16.7:123, mv.7=3D36, rs.7=3D0x188, ]HS.7=3D1844674407370952=
9383,^M^Jnow=3D0x
dd6b9112.c3c68d55, last.newest=3D0xdd6b90ee.777b2c6e^M^J

For a human it might be helpful if the sever could also give a description =
of the variable, but for a program something else would be needed.

If you look at SNMP or LDAP, TIFF tags or ASN.1 BER they all tell you the =
type of data sent at least...

Regards,
Ulrich



>=20
>=20
> --=20
> These are my opinions.  I hate spam.





From nobody Wed Sep 20 12:11:02 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 D0F17132A1A for ; Wed, 20 Sep 2017 12:11:00 -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] 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 gu5OmHhewlyV for ; Wed, 20 Sep 2017 12:10:59 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FE3134302 for ; Wed, 20 Sep 2017 12:10:55 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C2E65880ED for ; Wed, 20 Sep 2017 12:10:55 -0700 (PDT)
Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 933D53280AE4 for ; Wed, 20 Sep 2017 12:10:55 -0700 (PDT)
To: "ntp@ietf.org" 
References:  <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de>
From: Brian Haberman 
Message-ID: <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>
Date: Wed, 20 Sep 2017 15:10:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eBqR7rM0bpOI61sj5hMGnJtHOEWv7g8VK"
Archived-At: 
Subject: Re: [Ntp] Antw:  draft-ietf-ntp-mode-6-cmds : Issue 1
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, 20 Sep 2017 19:11:01 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--eBqR7rM0bpOI61sj5hMGnJtHOEWv7g8VK
Content-Type: multipart/mixed; boundary="pc4xOrW8OfgFxEhnTdhavULOPr3lW0C0K";
 protected-headers="v1"
From: Brian Haberman 
To: "ntp@ietf.org" 
Message-ID: <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>
Subject: Re: Antw: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 1
References: 
 <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de>
In-Reply-To: <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de>

--pc4xOrW8OfgFxEhnTdhavULOPr3lW0C0K
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable



On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>> Brian Haberman  schrieb am 18.09.2017 um 1=
9:10 in
> Nachricht :
>> Ulrich noted that this document does not specify a version number for
>> the mode 6 commands. I had suggested specifying it as "version 4 (or
>> earlier)" given that the introduction of mode 6 commands has occurred =
at
>> various versions of the protocol starting at RFC 1305. Ulrich pointed
>> out that the version number drives the interpretation of the status wo=
rds.
>>
>> For people who have implemented or use mode 6 commands, what makes sen=
se
>> here? Do we need to specify a version number per mode 6 command?
>=20
> Hi!
>=20
> I think there are several issues:
>=20
> 1) Assuming there are different versions (there are!), how can one find=
 out which version the server implements? See 2)
>=20
> 2) if a client requests a version different from the server, what shoul=
d the server do? The server could respond with a different version number=
, indicating that it is not willing to respond / privide the information =
in the format requested. Or the server could respond with a "bad request"=
 status. Finally the server could respond in the format requested... I ha=
ve slight favor for the first variant unless there is a command to find o=
ut what message format versions the server can provide.
>=20
> 3) As it seems to be now, the server ignores the version (versions 2, 3=
, and 4 all seem to work)
>=20

The above seems to argue for two things:

1) A preliminary handshake between an NTP server and the mode6-speaking
client to determine what version is in use.

2) A change to the operating basis of the mode 6 commands in that the
above mentioned handshake occurs before actually sending the mode 6 comma=
nd.

Is that a good representation of what is being asked for?

Brian


--pc4xOrW8OfgFxEhnTdhavULOPr3lW0C0K--

--eBqR7rM0bpOI61sj5hMGnJtHOEWv7g8VK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZwr09AAoJEGjWPJxT0YthMx4P/RiYsjSsJudoGgpjex/s4G/B
uTQzoCALkNwZZW9Zv08TwCWUy0d1F+Khl6CpVVCnwnFHnrJQg5u20kNtFRahhNlK
Itfu2TcHvc19W8J+wf6VsFN2Co5EC8X/6uwMALm2IEB2e6470AtSzhX7it+4cclh
nhpmCGNafV/BdxAQzY834XWdPV4q8v+kz+8TmxmudvoUEpO+n74P2J0YGww3fJU4
brcl7NQigar+kvpoL3d0Juskn5MAbeSDXhf5ZCQYRkJXOJE9+RmsqP6o9H+qqikm
skBSZJsngRtrLnT24e8hV5bOc7jo94LzkdSKiqZBAc3Y5Fay7JgDFMuCkp1VJEyH
4LG4BP+JwTJv/b49ETsXvzBfrFkLgbYiipN99+6Ctb0j9vG3mDm4DPbIYpQ0QU9z
esaec6gXkA7GVw2odi7TaJttlo/0RxMNCT2iDnFBKJnE4VZGjMuq0cZSlPlhHGuk
mbQMFMh3LtRIsZpf2tXWXTvYTID8+KBtavloJwjtY4BHSl69ymQyhbLqnJ8VPqzL
GiP47FLobPDaG2Cuqt7ru/+GApKv9UaOXcBE6cc3B/7gUjUHYgN8rtkQFuAbHD75
0ffuX0Iiu7m19+Xg9079ul2xHIXHSuxcXeR2sxoaO3HZwpMrVvHL+AG3VLpg5uIz
mRy1tCgGi7ZrPFWmrLQT
=i9ce
-----END PGP SIGNATURE-----

--eBqR7rM0bpOI61sj5hMGnJtHOEWv7g8VK--


From nobody Wed Sep 20 15:42:50 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 8A95B1243F6 for ; Wed, 20 Sep 2017 15:42:48 -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, 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 z9h5UK-U3TbL for ; Wed, 20 Sep 2017 15:42:47 -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 5AE59132F3E for ; Wed, 20 Sep 2017 15:42:24 -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 07A9EB856; Wed, 20 Sep 2017 22:42:23 +0000 (UTC)
To: ntp@ietf.org
References:  <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>
From: Harlan Stenn 
Message-ID: 
Date: Wed, 20 Sep 2017 15:42:23 -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: <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Ntp] Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
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, 20 Sep 2017 22:42:48 -0000

On 9/20/17 12:10 PM, Brian Haberman wrote:
> 
> 
> On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>>> Brian Haberman  schrieb am 18.09.2017 um 19:10 in
>> Nachricht :
>>> Ulrich noted that this document does not specify a version number for
>>> the mode 6 commands. I had suggested specifying it as "version 4 (or
>>> earlier)" given that the introduction of mode 6 commands has occurred at
>>> various versions of the protocol starting at RFC 1305. Ulrich pointed
>>> out that the version number drives the interpretation of the status words.
>>>
>>> For people who have implemented or use mode 6 commands, what makes sense
>>> here? Do we need to specify a version number per mode 6 command?
>>
>> Hi!
>>
>> I think there are several issues:
>>
>> 1) Assuming there are different versions (there are!), how can one find out which version the server implements? See 2)
>>
>> 2) if a client requests a version different from the server, what should the server do? The server could respond with a different version number, indicating that it is not willing to respond / privide the information in the format requested. Or the server could respond with a "bad request" status. Finally the server could respond in the format requested... I have slight favor for the first variant unless there is a command to find out what message format versions the server can provide.
>>
>> 3) As it seems to be now, the server ignores the version (versions 2, 3, and 4 all seem to work)
>>
> 
> The above seems to argue for two things:
> 
> 1) A preliminary handshake between an NTP server and the mode6-speaking
> client to determine what version is in use.
> 
> 2) A change to the operating basis of the mode 6 commands in that the
> above mentioned handshake occurs before actually sending the mode 6 command.
> 
> Is that a good representation of what is being asked for?

If it is, I'm thinking we'd want a mode 6 "Identify" command, that would
have this information in a response.  This response would likely contain
different data before/after authentication.

I'd also much rather we had changes to do this that are tested and known
to do what we want instead of codifying what folks hope will be a good
solution.

I'm happy to work with collaborative folks, experienced or not, who want
to dig in to this.

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!


From nobody Thu Sep 21 06:24: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 3BBB1134B49 for ; Thu, 21 Sep 2017 06:24:06 -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] 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 poxxZzqTP_cl for ; Thu, 21 Sep 2017 06:24:05 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E820132403 for ; Thu, 21 Sep 2017 06:24:05 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 027A788129 for ; Thu, 21 Sep 2017 06:24:05 -0700 (PDT)
Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id B4C3A3280AE4 for ; Thu, 21 Sep 2017 06:24:04 -0700 (PDT)
To: ntp@ietf.org
References:  <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> 
From: Brian Haberman 
Message-ID: <577e04bd-accc-be00-fbd0-3528a0ae6250@innovationslab.net>
Date: Thu, 21 Sep 2017 09:23:58 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lQgX9O2GDWuAk16NrvKhOlFoUfmWLEhtV"
Archived-At: 
Subject: Re: [Ntp] Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
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: Thu, 21 Sep 2017 13:24:06 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--lQgX9O2GDWuAk16NrvKhOlFoUfmWLEhtV
Content-Type: multipart/mixed; boundary="sLQ8veLxtgsVhIpsGUVsFCFeI069FPicU";
 protected-headers="v1"
From: Brian Haberman 
To: ntp@ietf.org
Message-ID: <577e04bd-accc-be00-fbd0-3528a0ae6250@innovationslab.net>
Subject: Re: [Ntp] Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
References: 
 <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de>
 <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>
 
In-Reply-To: 

--sLQ8veLxtgsVhIpsGUVsFCFeI069FPicU
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hi Harlan,

On 9/20/17 6:42 PM, Harlan Stenn wrote:

>>
>> The above seems to argue for two things:
>>
>> 1) A preliminary handshake between an NTP server and the mode6-speakin=
g
>> client to determine what version is in use.
>>
>> 2) A change to the operating basis of the mode 6 commands in that the
>> above mentioned handshake occurs before actually sending the mode 6 co=
mmand.
>>
>> Is that a good representation of what is being asked for?
>=20
> If it is, I'm thinking we'd want a mode 6 "Identify" command, that woul=
d
> have this information in a response.  This response would likely contai=
n
> different data before/after authentication.
>=20
> I'd also much rather we had changes to do this that are tested and know=
n
> to do what we want instead of codifying what folks hope will be a good
> solution.
>=20
> I'm happy to work with collaborative folks, experienced or not, who wan=
t
> to dig in to this.
>=20

This document is controlled by the consensus of the WG. So it is up to
the participants interested in adding such functionality to "drum up the
support" for adding it to the draft.

Regards,
Brian


--sLQ8veLxtgsVhIpsGUVsFCFeI069FPicU--

--lQgX9O2GDWuAk16NrvKhOlFoUfmWLEhtV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZw71zAAoJEGjWPJxT0YthFLIP/R6K5XheNaR3almVU7Pmj516
wgNLyRSDCA7l3nWm9/Rr1WxxXFoVq4XC5XiIEL6btHpYcYKICf3TVHXxJkfYRHJe
K5tnhDD8JwnoG3fA3fuqvVkgNJwDt0Xy3+/bCnz/JBEglBcx35okknzM08yu/1QQ
Z3zQDwrMkQld+G9ITDK8ZZzIejybvh8nhtCelD83DJuF/hzosPtbLG/RS6FNyzbL
RzMlHhuyJSDiHc8W302huFOIipxdAVjSUQtqx0WgUJDRIqW27awhTIFlz9oTrOoI
DpUY4si08UcYmteHbsR7YivR4Qv8HDpgImjY/PVBn4ljQArInyrQ+/Y05Uf5y8VV
zdnDL3eozxhxULPpAx2ZtmLzU5LN2x8KMcZS+aUJTcSbRkLHWgrjomjmM7x28Imx
EzV8rLp43GfhHhhxOwZOY8TzYEE4eywzRHlyMU2bj6lSnkdqJlkh7m5j5a6mXbYW
P7euoPaxyEs2m9YdlCL7ct/5dKjfH+l39N1HRi8knfJ72hzS7T5GtnZ3RV8//VEw
ZApYd3litD9/Z7c24Dchzu1QYnjDGTEFnzHE4+oIKcTfiLTxGOf0fhWFwbNpd+kX
RSOvv/QG3BYWgHyNgGQjo7sZUQMz0PqofJccbv2wYZFk3we+ufUWOcn7oMmBnVAh
2JGA9/A5lZDdS2CRwDOd
=u1fN
-----END PGP SIGNATURE-----

--lQgX9O2GDWuAk16NrvKhOlFoUfmWLEhtV--


From nobody Thu Sep 21 23:02:27 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 48ECD132939 for ; Thu, 21 Sep 2017 23:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 gdDET-RJr6tW for ; Thu, 21 Sep 2017 23:02:23 -0700 (PDT)
Received: from rrzmta2.uni-regensburg.de (rrzmta2.uni-regensburg.de [194.94.155.52]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CBE1321A1 for ; Thu, 21 Sep 2017 23:02:22 -0700 (PDT)
Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C4423795C2 for ; Fri, 22 Sep 2017 08:02:20 +0200 (CEST)
Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 99D97793FD for ; Fri, 22 Sep 2017 08:02:20 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Fri, 22 Sep 2017 08:02:20 +0200
Message-Id: <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Fri, 22 Sep 2017 08:02:17 +0200
From: "Ulrich Windl" 
To: "ntp@ietf.org" ,
References:  <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net> 
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:  Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
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: Fri, 22 Sep 2017 06:02:25 -0000

>>> Harlan Stenn  schrieb am 21.09.2017 um 00:42 in =
Nachricht
:

>=20
> On 9/20/17 12:10 PM, Brian Haberman wrote:
>>=20
>>=20
>> On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>>>> Brian Haberman  schrieb am 18.09.2017 um =
19:10 in
>>> Nachricht :
>>>> Ulrich noted that this document does not specify a version number for
>>>> the mode 6 commands. I had suggested specifying it as "version 4 (or
>>>> earlier)" given that the introduction of mode 6 commands has occurred =
at
>>>> various versions of the protocol starting at RFC 1305. Ulrich pointed
>>>> out that the version number drives the interpretation of the status =
words.
>>>>
>>>> For people who have implemented or use mode 6 commands, what makes =
sense
>>>> here? Do we need to specify a version number per mode 6 command?
>>>
>>> Hi!
>>>
>>> I think there are several issues:
>>>
>>> 1) Assuming there are different versions (there are!), how can one =
find out=20
> which version the server implements? See 2)
>>>
>>> 2) if a client requests a version different from the server, what =
should the=20
> server do? The server could respond with a different version number,=20
> indicating that it is not willing to respond / privide the information =
in the=20
> format requested. Or the server could respond with a "bad request" =
status.=20
> Finally the server could respond in the format requested... I have =
slight=20
> favor for the first variant unless there is a command to find out =
what=20
> message format versions the server can provide.
>>>
>>> 3) As it seems to be now, the server ignores the version (versions 2, =
3, and=20
> 4 all seem to work)
>>>
>>=20
>> The above seems to argue for two things:
>>=20
>> 1) A preliminary handshake between an NTP server and the mode6-speaking
>> client to determine what version is in use.
>>=20
>> 2) A change to the operating basis of the mode 6 commands in that the
>> above mentioned handshake occurs before actually sending the mode 6 =
command.
>>=20
>> Is that a good representation of what is being asked for?
>=20
> If it is, I'm thinking we'd want a mode 6 "Identify" command, that would
> have this information in a response.  This response would likely contain
> different data before/after authentication.

Why that? You should elaborate on the role of authentication.

>=20
> I'd also much rather we had changes to do this that are tested and known
> to do what we want instead of codifying what folks hope will be a good
> solution.
>=20
> I'm happy to work with collaborative folks, experienced or not, who want
> to dig in to this.
>=20
> --=20
> Harlan Stenn 
> http://networktimefoundation.org - be a member!
>=20
> _______________________________________________
> ntp mailing list
> ntp@ietf.org=20
> https://www.ietf.org/mailman/listinfo/ntp=20





From nobody Thu Sep 21 23:26:48 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 DCFA4134217 for ; Thu, 21 Sep 2017 23:26:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bSjSwMSn8VaC for ; Thu, 21 Sep 2017 23:26:45 -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 4E7D4133187 for ; Thu, 21 Sep 2017 23:26:45 -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 3713DB87A; Fri, 22 Sep 2017 06:26:44 +0000 (UTC)
To: Ulrich Windl , "ntp@ietf.org" 
References:  <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>  <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de>
From: Harlan Stenn 
Message-ID: <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>
Date: Thu, 21 Sep 2017 23:26:42 -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: <59C4A769020000A100028053@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:  Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
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: Fri, 22 Sep 2017 06:26:47 -0000

On 9/21/17 11:02 PM, Ulrich Windl wrote:
>>>> Harlan Stenn  schrieb am 21.09.2017 um 00:42 in Nachricht
> :
> 
>>
>> On 9/20/17 12:10 PM, Brian Haberman wrote:
>>>
>>>
>>> On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>>>>> Brian Haberman  schrieb am 18.09.2017 um 19:10 in
>>>> Nachricht :
>>>>> Ulrich noted that this document does not specify a version number for
>>>>> the mode 6 commands. I had suggested specifying it as "version 4 (or
>>>>> earlier)" given that the introduction of mode 6 commands has occurred at
>>>>> various versions of the protocol starting at RFC 1305. Ulrich pointed
>>>>> out that the version number drives the interpretation of the status words.
>>>>>
>>>>> For people who have implemented or use mode 6 commands, what makes sense
>>>>> here? Do we need to specify a version number per mode 6 command?
>>>>
>>>> Hi!
>>>>
>>>> I think there are several issues:
>>>>
>>>> 1) Assuming there are different versions (there are!), how can one find out 
>> which version the server implements? See 2)
>>>>
>>>> 2) if a client requests a version different from the server, what should the 
>> server do? The server could respond with a different version number, 
>> indicating that it is not willing to respond / privide the information in the 
>> format requested. Or the server could respond with a "bad request" status. 
>> Finally the server could respond in the format requested... I have slight 
>> favor for the first variant unless there is a command to find out what 
>> message format versions the server can provide.
>>>>
>>>> 3) As it seems to be now, the server ignores the version (versions 2, 3, and 
>> 4 all seem to work)
>>>>
>>>
>>> The above seems to argue for two things:
>>>
>>> 1) A preliminary handshake between an NTP server and the mode6-speaking
>>> client to determine what version is in use.
>>>
>>> 2) A change to the operating basis of the mode 6 commands in that the
>>> above mentioned handshake occurs before actually sending the mode 6 command.
>>>
>>> Is that a good representation of what is being asked for?
>>
>> If it is, I'm thinking we'd want a mode 6 "Identify" command, that would
>> have this information in a response.  This response would likely contain
>> different data before/after authentication.
> 
> Why that? You should elaborate on the role of authentication.

Here's a short list.

- Nobody but trusted folks should see the origin timestamp of a pending
  symmetric mode exchange.

- Nobody but trusted folks should be able to get the list of our
  potential servers.

- Nobody but VERY trusted folks should be able to issue :config
  directives

>> I'd also much rather we had changes to do this that are tested and known
>> to do what we want instead of codifying what folks hope will be a good
>> solution.
>>
>> I'm happy to work with collaborative folks, experienced or not, who want
>> to dig in to this.

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!


From nobody Fri Sep 22 00:05:34 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 2F442132932 for ; Fri, 22 Sep 2017 00:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 iIi5Hqw1cFSc for ; Fri, 22 Sep 2017 00:05:30 -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 2D59B1252BA for ; Fri, 22 Sep 2017 00:05:30 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A50485D864 for ; Fri, 22 Sep 2017 09:05:28 +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 753B75D505 for ; Fri, 22 Sep 2017 09:05:28 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Fri, 22 Sep 2017 09:05:28 +0200
Message-Id: <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.2 
Date: Fri, 22 Sep 2017 09:05:26 +0200
From: "Ulrich Windl" 
To: "ntp@ietf.org" ,
References:  <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>  <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>
In-Reply-To: <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: 
Subject: Re: [Ntp] Antw: Re:  Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
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: Fri, 22 Sep 2017 07:05:32 -0000

>>> Harlan Stenn  schrieb am 22.09.2017 um 08:26 in =
Nachricht
<579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>:

> On 9/21/17 11:02 PM, Ulrich Windl wrote:
>>>>> Harlan Stenn  schrieb am 21.09.2017 um 00:42 in =
Nachricht
>> :
>>=20
>>>
>>> On 9/20/17 12:10 PM, Brian Haberman wrote:
>>>>
>>>>
>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>>>>>> Brian Haberman  schrieb am 18.09.2017 =
um 19:10 in
>>>>> Nachricht :
>>>>>> Ulrich noted that this document does not specify a version number =
for
>>>>>> the mode 6 commands. I had suggested specifying it as "version 4 =
(or
>>>>>> earlier)" given that the introduction of mode 6 commands has =
occurred at
>>>>>> various versions of the protocol starting at RFC 1305. Ulrich =
pointed
>>>>>> out that the version number drives the interpretation of the status =
words.
>>>>>>
>>>>>> For people who have implemented or use mode 6 commands, what makes =
sense
>>>>>> here? Do we need to specify a version number per mode 6 command?
>>>>>
>>>>> Hi!
>>>>>
>>>>> I think there are several issues:
>>>>>
>>>>> 1) Assuming there are different versions (there are!), how can one =
find out=20
>>> which version the server implements? See 2)
>>>>>
>>>>> 2) if a client requests a version different from the server, what =
should the=20
>=20
>>> server do? The server could respond with a different version number,=20=

>>> indicating that it is not willing to respond / privide the information =
in=20
> the=20
>>> format requested. Or the server could respond with a "bad request" =
status.=20
>>> Finally the server could respond in the format requested... I have =
slight=20
>>> favor for the first variant unless there is a command to find out =
what=20
>>> message format versions the server can provide.
>>>>>
>>>>> 3) As it seems to be now, the server ignores the version (versions =
2, 3, and=20
>=20
>>> 4 all seem to work)
>>>>>
>>>>
>>>> The above seems to argue for two things:
>>>>
>>>> 1) A preliminary handshake between an NTP server and the mode6-speakin=
g
>>>> client to determine what version is in use.
>>>>
>>>> 2) A change to the operating basis of the mode 6 commands in that the
>>>> above mentioned handshake occurs before actually sending the mode 6 =
command.
>>>>
>>>> Is that a good representation of what is being asked for?
>>>
>>> If it is, I'm thinking we'd want a mode 6 "Identify" command, that =
would
>>> have this information in a response.  This response would likely =
contain
>>> different data before/after authentication.
>>=20
>> Why that? You should elaborate on the role of authentication.
>=20
> Here's a short list.
>=20
> - Nobody but trusted folks should see the origin timestamp of a pending
>   symmetric mode exchange.
>=20
> - Nobody but trusted folks should be able to get the list of our
>   potential servers.
>=20
> - Nobody but VERY trusted folks should be able to issue :config
>   directives

Hi Harlan,

even more confused now: The issue was (unless I'm confused) to finde out =
what mode-6 protocol version the remote side (server) speaks.
You talk about changing the requirements of existing commands (it seems).
I have no objection changing the require ments on the next mode-6 protocol =
level, but these issues should be clearly separated IMHO.

Regards,
Ulrich



>=20
>>> I'd also much rather we had changes to do this that are tested and =
known
>>> to do what we want instead of codifying what folks hope will be a good
>>> solution.
>>>
>>> I'm happy to work with collaborative folks, experienced or not, who =
want
>>> to dig in to this.
>=20
> --=20
> Harlan Stenn 
> http://networktimefoundation.org - be a member!





From nobody Fri Sep 22 00:47:15 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 A102F132EA7 for ; Fri, 22 Sep 2017 00:47:14 -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, 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 ALkpbr4fLq6e for ; Fri, 22 Sep 2017 00:47:12 -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 B127D127005 for ; Fri, 22 Sep 2017 00:47:12 -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 E50E2B858; Fri, 22 Sep 2017 07:47:11 +0000 (UTC)
To: Ulrich Windl , "ntp@ietf.org" 
References:  <59C0BEBB020000A100027F1A@gwsmtp1.uni-regensburg.de> <90ca0015-6ff4-9f68-20c9-a978fea6f491@innovationslab.net>  <59C4A769020000A100028053@gwsmtp1.uni-regensburg.de> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org> <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de>
From: Harlan Stenn 
Message-ID: <62ae5e81-593f-e26a-8829-bc5f4be07dab@nwtime.org>
Date: Fri, 22 Sep 2017 00:47:11 -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: <59C4B636020000A100028076@gwsmtp1.uni-regensburg.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Ntp] Antw: Re:  Antw: draft-ietf-ntp-mode-6-cmds : Issue 1
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: Fri, 22 Sep 2017 07:47:15 -0000

On 9/22/2017 12:05 AM, Ulrich Windl wrote:
>>>> Harlan Stenn  schrieb am 22.09.2017 um 08:26 in Nachricht
> <579cec94-f2ab-ce73-13f6-483f5c528da7@nwtime.org>:
> 
>> On 9/21/17 11:02 PM, Ulrich Windl wrote:
>>>>>> Harlan Stenn  schrieb am 21.09.2017 um 00:42 in Nachricht
>>> :
>>>
>>>>
>>>> On 9/20/17 12:10 PM, Brian Haberman wrote:
>>>>>
>>>>>
>>>>> On 9/19/17 2:52 AM, Ulrich Windl wrote:
>>>>>>>>> Brian Haberman  schrieb am 18.09.2017 um 19:10 in
>>>>>> Nachricht :
>>>>>>> Ulrich noted that this document does not specify a version number for
>>>>>>> the mode 6 commands. I had suggested specifying it as "version 4 (or
>>>>>>> earlier)" given that the introduction of mode 6 commands has occurred at
>>>>>>> various versions of the protocol starting at RFC 1305. Ulrich pointed
>>>>>>> out that the version number drives the interpretation of the status words.
>>>>>>>
>>>>>>> For people who have implemented or use mode 6 commands, what makes sense
>>>>>>> here? Do we need to specify a version number per mode 6 command?
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I think there are several issues:
>>>>>>
>>>>>> 1) Assuming there are different versions (there are!), how can one find out 
>>>> which version the server implements? See 2)
>>>>>>
>>>>>> 2) if a client requests a version different from the server, what should the 
>>
>>>> server do? The server could respond with a different version number, 
>>>> indicating that it is not willing to respond / privide the information in 
>> the 
>>>> format requested. Or the server could respond with a "bad request" status. 
>>>> Finally the server could respond in the format requested... I have slight 
>>>> favor for the first variant unless there is a command to find out what 
>>>> message format versions the server can provide.
>>>>>>
>>>>>> 3) As it seems to be now, the server ignores the version (versions 2, 3, and 
>>
>>>> 4 all seem to work)
>>>>>>
>>>>>
>>>>> The above seems to argue for two things:
>>>>>
>>>>> 1) A preliminary handshake between an NTP server and the mode6-speaking
>>>>> client to determine what version is in use.
>>>>>
>>>>> 2) A change to the operating basis of the mode 6 commands in that the
>>>>> above mentioned handshake occurs before actually sending the mode 6 command.
>>>>>
>>>>> Is that a good representation of what is being asked for?
>>>>
>>>> If it is, I'm thinking we'd want a mode 6 "Identify" command, that would
>>>> have this information in a response.  This response would likely contain
>>>> different data before/after authentication.
>>>
>>> Why that? You should elaborate on the role of authentication.
>>
>> Here's a short list.
>>
>> - Nobody but trusted folks should see the origin timestamp of a pending
>>   symmetric mode exchange.
>>
>> - Nobody but trusted folks should be able to get the list of our
>>   potential servers.
>>
>> - Nobody but VERY trusted folks should be able to issue :config
>>   directives
> 
> Hi Harlan,
> 
> even more confused now: The issue was (unless I'm confused) to finde out what mode-6 protocol version the remote side (server) speaks.
> You talk about changing the requirements of existing commands (it seems).
> I have no objection changing the require ments on the next mode-6 protocol level, but these issues should be clearly separated IMHO.

I thought the intent was to make sure that ntpq could ask an NTP server
"what can you tell me about yourself?", in enough detail that the client
will then know what to ask, and how to interpret the results.

H
--
> Regards,
> Ulrich
> 
> 
> 
>>
>>>> I'd also much rather we had changes to do this that are tested and known
>>>> to do what we want instead of codifying what folks hope will be a good
>>>> solution.
>>>>
>>>> I'm happy to work with collaborative folks, experienced or not, who want
>>>> to dig in to this.
>>
>> -- 
>> Harlan Stenn 
>> http://networktimefoundation.org - be a member!
> 
> 
> 
> 
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!


From nobody Sun Sep 24 06:37:34 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 1CAE113308A; Sun, 24 Sep 2017 06:37:34 -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 loosToXTyGVP; Sun, 24 Sep 2017 06:37:32 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 63507133087; Sun, 24 Sep 2017 06:37:32 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id b1so3804776oih.4; Sun, 24 Sep 2017 06:37:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=MzkndDkp9tmeQbqDuxisLzt7LtHDfbyu5exkvpE1Yd0=; b=kVqLDMHMmU7PZ3w1BBE/p5cqVvOD9NUhCNEqYCWnwRQKF8DAoVPIzi5T9RSMgqtoxQ dDTvFqIurAwDu9amakZ78LXP/N3W1pr8hK4+CAlwgVRvSivHt15ZpxMrPy7lAl+ALHfA iQuj5VV55y9WZOVh2J+xljv0D13NGxVcCbrPpxco3ldnwdtqUiz+sQelHe/3vuqmZFcP 9v34xiOsXdYSMDqr9jBTsJpIhLrtlhKTlETSf4EClmlevUtIAcouC6jR0hbxZkwYRACU Z3T+aR0qAvXO1N+cBv32aB3AEVqzSeP/banxUqYCENV/e2t0YwQKBrrtl7J209ntsZKT t1XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MzkndDkp9tmeQbqDuxisLzt7LtHDfbyu5exkvpE1Yd0=; b=BW77n6Tzg5PVIr9lLe0bt86OJCraMceJkb+4IA5GMez0SvwtgCyT6aFlf7KNHzt82H tWrSLsA/iIDrtDmxcu8SOHnIPY4jFVODomve87wphs7ghwOBjzjqA2BdzfSBXmUHyrjY rfIzQOTUeo0vM0l3HpU/jmdh5hqq8BsGVoUfCF0qcz79s1Glkx5DAkUZUY9rE0ZoXuAE ytkMxg9l8Mb1p5dkqxKrY4EbX8uSU2dPTWpld8J82frDIDg13Z5WjC74L4CiFnapDZly FgGsbkojmpZo1/P5hjqDAwvzObu12dQUYZcH0gMn6qQI0JKh10Zp3v0BUmGSOZy+tVfb fiiw==
X-Gm-Message-State: AHPjjUgkCYfwU3DkIisAfkZIAtyfrsuA+nAnp33dFmuOtDyTldOxgh9M pf9PT6LS0wlitBxYjIzsZ2B3YOsmv+pAcEYS7G8cIA==
X-Google-Smtp-Source: AOwi7QDpvwe3tiZ0VNjrB1OPVS7NVK1bVupijd7NofrPjwVWVZHpWhxqpiFZSE/GNO7ha0YAJ5W2RruOwRNycSGlTzs=
X-Received: by 10.202.45.205 with SMTP id t196mr5153347oit.111.1506260251692;  Sun, 24 Sep 2017 06:37:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.168.181.200 with HTTP; Sun, 24 Sep 2017 06:37:31 -0700 (PDT)
From: Tal Mizrahi 
Date: Sun, 24 Sep 2017 16:37:31 +0300
Message-ID: 
To: tictoc@ietf.org, ntp@ietf.org
Content-Type: multipart/alternative; boundary="001a1137b9103dd2fc0559ef8b45"
Archived-At: 
Subject: [Ntp] Guidelines for Defining Packet Timestamps
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: Sun, 24 Sep 2017 13:37:34 -0000

--001a1137b9103dd2fc0559ef8b45
Content-Type: text/plain; charset="UTF-8"

Hi,

We have revised the draft based on the comments received in IETF 99, and
based on the comments from Yaakov (thanks Yaakov).

https://datatracker.ietf.org/doc/draft-mizrahi-intarea-packet-timestamps/

The main changes compared to the previous version of the draft:
- We have extended the discussion about the factors that may affect the
choice of the timestamp format.
- A new section has been added, called "Timestamp Use Cases".
- The sychronization aspects have been separated from the timestamp format,
allowing the timestamp format to be independent of how time is synchronized.

Any further comments are welcome.

Cheers,
Tal, Joachim, and Al.

--001a1137b9103dd2fc0559ef8b45
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

We have revised the draft bas=
ed on the comments received in IETF 99, and based on the comments from Yaak=
ov (thanks Yaakov).

https://da=
tatracker.ietf.org/doc/draft-mizrahi-intarea-packet-timestamps/

The main changes compared to the previous version of =
the draft:
- We have extended the discussion about the factors th=
at may affect the choice of the timestamp format.
- A new section=
 has been added, called "Timestamp Use Cases".
- The sy=
chronization aspects have been separated from the timestamp format, allowin=
g the timestamp format to be independent of how time is synchronized.
=


Any further comments are welcome.

Cheers,
Tal, Joachim, and Al.


--001a1137b9103dd2fc0559ef8b45--


From wlosh@bsdimp.com  Sun Sep 24 08:06:48 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 4A8EF132403 for ; Sun, 24 Sep 2017 08:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bsdimp-com.20150623.gappssmtp.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 vIV-oItSY7jn for ; Sun, 24 Sep 2017 08:06:46 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 ECB1B124207 for ; Sun, 24 Sep 2017 08:06:45 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id y138so4949055itc.5 for ; Sun, 24 Sep 2017 08:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DiAArg/CaRi2BfH2jOy37J8ekKMoAWN2BGaSkmekkXM=; b=bf2pjosw75vqtbFGxf9xq0iKko0uKS3526HCekEVXP2DHhr710AjFfTox0MUlgKXS+ tv7sFH+pmOtiaHV7bk9I88fSTQZ7fjOStdqUF/VWjjftwKoJZ6rMlboU9CGpE9IPirDN kRdUJwpXYyCiJX4yLJqERpxIbugslkhgLOhlsuyaZZ/0vhdVr1Gxsz+zlw42a27H64V7 akke/Kbpvy2JFTrmDHj5vUFmOJSwXSrXjHMnGrGLDyiwAGzBxz9C2j2F2uiWJ7+eA+xT 32xvm/Q3KqSD396HjZPshmszLrUONeWVej/caFf8eLzMy3bkxTZ1Umb26gkDIGSqTqEe gqPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DiAArg/CaRi2BfH2jOy37J8ekKMoAWN2BGaSkmekkXM=; b=RGnuEPk1H5BjBof5tfraI5tyQPs3U0jaobTvTWSf9+/rULchI9kZXcKLvexnlej6wn wOrtSPy8gVwpUgDyRcvQil1AFdOLgn6CrQyOMFQ3uH5+NvZq61nOClZgSpvdbJ7jBPPG FSTVLZ62RpCs+jZSe/003Y2kd46Hz4HnGx6expfJlo5Ct2wFPN1KSI7IIDmM7we2Klof 8WMlRr5a99hTNfnSyqfX4ZBrcamXOuf9Wbi68l/F/GPf2iLUb4R6Gbqp/E8FZYHczh+y rq2en8AVjzcVS0TMOQtQ8+0ZNc25jnI+XBBfmKj4G1BDXi/NaWkGzRIt3yB4+YiHPa4/ ncbQ==
X-Gm-Message-State: AHPjjUjKwJnYDZ9eB+K7yyx+UHMQ9Nol1S45VENL0KVfKIQvDinuFDGY y4YudNDT50UpWKUEuwfZNEPikgAx8fYf9URu17FMDQ==
X-Google-Smtp-Source: AOwi7QA5y7pp2T1L5tHkaNPIfafSD6nqSUT4O9OBi8spR6LYDaYz0SZAAVJFlGVF7O/QrWdPWM5VLLstfwROC+V6TIY=
X-Received: by 10.36.179.79 with SMTP id z15mr14598168iti.26.1506265605048; Sun, 24 Sep 2017 08:06:45 -0700 (PDT)
MIME-Version: 1.0
Sender: wlosh@bsdimp.com
Received: by 10.79.2.194 with HTTP; Sun, 24 Sep 2017 08:06:44 -0700 (PDT)
X-Originating-IP: [50.253.99.174]
In-Reply-To: 
References: 
From: Warner Losh 
Date: Sun, 24 Sep 2017 09:06:44 -0600
X-Google-Sender-Auth: FXer1UV67iH2R_uwJMeLLnvVZqo
Message-ID: 
To: Tal Mizrahi 
Cc: tictoc@ietf.org, ntp@ietf.org
Content-Type: multipart/alternative; boundary="f403043a6f5c539f0f0559f0cad0"
Archived-At: 
Subject: Re: [Ntp] Guidelines for Defining Packet Timestamps
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: Sun, 24 Sep 2017 15:08:48 -0000

--f403043a6f5c539f0f0559f0cad0
Content-Type: text/plain; charset="UTF-8"

On Sun, Sep 24, 2017 at 7:37 AM, Tal Mizrahi 
wrote:

> Hi,
>
> We have revised the draft based on the comments received in IETF 99, and
> based on the comments from Yaakov (thanks Yaakov).
>
> https://datatracker.ietf.org/doc/draft-mizrahi-intarea-packet-timestamps/
>
> The main changes compared to the previous version of the draft:
> - We have extended the discussion about the factors that may affect the
> choice of the timestamp format.
> - A new section has been added, called "Timestamp Use Cases".
> - The sychronization aspects have been separated from the timestamp
> format, allowing the timestamp format to be independent of how time is
> synchronized.
>
> Any further comments are welcome.
>

Section 4.1 says "Further considerations may be discussed in this section,
such as required accuracy, or leap second handling." Yet none of the
formats make any allowance for leap seconds. In NTP headers, leap second
time stamps are marked with an out-of-band bit. In addition, all NTP time
stamps are adjusted by the cumulative number of leap seconds, yet that
relevant information is not included.PTP timestamps, on the other hand, are
a count of TAI seconds since 1970, which have no adjustments.

When I was doing time and frequency recovery, these differences weren't
documented and many arguments ensued to get to the understanding of what's
actually on the wire, what the auxiliary bits mean, etc. I'd rather see
this document be explicit about such things rather than some vague hand
wave that will be interpreted in many different ways leading to even more
issues with leap seconds than we already have.

Warner

--f403043a6f5c539f0f0559f0cad0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sun, Sep 24, 2017 at 7:37 AM, Tal Mizrahi <tal.mizrahi.phd@=
gmail.com> wrote:
Hi,=C2=A0

We have revised th=
e draft based on the comments received in IETF 99, and based on the comment=
s from Yaakov (thanks Yaakov).


The main chang=
es compared to the previous version of the draft:
- We have exten=
ded the discussion about the factors that may affect the choice of the time=
stamp format.
- A new section has been added, called "Timest=
amp Use Cases".
- The sychronization aspects have been separ=
ated from the timestamp format, allowing the timestamp format to be indepen=
dent of how time is synchronized.

Any further comm=
ents are welcome.

Section=
 4.1 says "Fur=
ther considerations=C2=A0may be discussed in this section, such as required accuracy, o=
r leap secon=
d handling." Yet none of the formats make any allowance for leap secon=
ds. In NTP headers, leap second time stamps are marked with an out-of-band =
bit. In addition, all NTP time stamps are adjusted by the cumulative number=
 of leap seconds, yet that relevant information is not included.PTP timesta=
mps, on the other hand, are a count of TAI seconds since 1970, which have n=
o adjustments.

When I was doing time and frequency recovery, these differences w=
eren't documented and many arguments ensued to get to the understanding=
 of what's actually on the wire, what the auxiliary bits mean, etc. I&#=
39;d rather see this document be explicit about such things rather than som=
e vague hand wave that will be interpreted in many different ways leading t=
o even more issues with leap seconds than we already have.

Warner=



--f403043a6f5c539f0f0559f0cad0--


From nobody Sun Sep 24 23:37:52 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 05D3F126B6D; Sun, 24 Sep 2017 23:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, 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 aMXSEXjF6DEm; Sun, 24 Sep 2017 23:37:48 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 95C1512426E; Sun, 24 Sep 2017 23:37:48 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id x85so5527531oix.12; Sun, 24 Sep 2017 23:37:48 -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=YdJ7EDvEIcocD4fJoTTueADB8VgXRlUcj745BxLSsoM=; b=cIj6daeHKKgjZtPEA8EPdV2HHi54MWOR0CCj38RG+S15obrdevAWGQX0c8s4CGjLxK LXFAaR5emNMWGTFCJapuhBPpwId6t801lJjCNf7YiZ/QmNTWQNrf27frjapowF3nVaiU 24NdFP8ZhJ8cy4Ek9cEmiOfGmYdOGuTRwJaOXyRyFuCRIji2RBcn9Pk6UD/uPWLn6Qpw zn5Tz4ztoBY+tW5R0nP0pe/RVtFP9YsyjQ2mcV6zdJzQzWt02jok5TrEmy/USfHwLGUo LB6z1XkKFUOe2+4imN375+Cy6ubz0eac8jC0TSUA21cCOOllNLN+3oiBUNFTxomkRA03 r0cA==
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=YdJ7EDvEIcocD4fJoTTueADB8VgXRlUcj745BxLSsoM=; b=XQkMa2rx/hHpQ0eAMWUJf+ad4PjfXRKLD+6wlXtE6RVssei9gkuO5RFvdUKY+swura 2F02Vw4MvdcmkB55cY5huW1/X9dJPi5Qqsd6CnegNudcGHcVHSm9er/Ehw2vQyJSLXSU FE3tcZ+hqz25AoNqM8ci3XFy1+6oQ6ZRkiidbDM8PnwE0rm61a0UxqHN1QYo+95yl9lh gYMgDX+e6R+/evxQv/abBjpYM96eoHemuWuMLat/hnPnU05q+2sZLpjRve6W3EzprS3L Np0OVDCf5CU0xSjxYfXLu5Pg3g1SdJUDXKhLI9yoJ6Gevdx18Am1AiuXXwu/QwPPCg6I OTkw==
X-Gm-Message-State: AHPjjUgBhwgqvdo2r3/ui6BBaNcwMzhRsjfmH/B2+Nq8fxhRuifQNfxb sSEKdY4AhX43tmO3AFQ7jqcsj8z6eb0ERo+BizA=
X-Google-Smtp-Source: AOwi7QAwbDK1tWIQjxOz87DeMINQl7rWDWZ0oIoWwmPwMUQC02RJ5N/WdnfmFiK4t6ZsRyyubDg4SlOU9MxHvoz5uHY=
X-Received: by 10.202.104.198 with SMTP id o67mr8214037oik.280.1506321467682;  Sun, 24 Sep 2017 23:37:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.168.181.200 with HTTP; Sun, 24 Sep 2017 23:37:47 -0700 (PDT)
In-Reply-To: 
References:  
From: Tal Mizrahi 
Date: Mon, 25 Sep 2017 09:37:47 +0300
Message-ID: 
To: Warner Losh 
Cc: tictoc@ietf.org, ntp@ietf.org
Content-Type: multipart/alternative; boundary="001a1140a9b0ffb59d0559fdcb57"
Archived-At: 
Subject: Re: [Ntp] Guidelines for Defining Packet Timestamps
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, 25 Sep 2017 06:37:51 -0000

--001a1140a9b0ffb59d0559fdcb57
Content-Type: text/plain; charset="UTF-8"

Hi Warner,

Thanks for the feedback.


>Section 4.1 says "Further considerations may be discussed in
>this section, such as required accuracy, or leap second handling."
>Yet none of the formats make any allowance for leap seconds.

Right. As I pointed out below, we have separated the *formats* from the
*synchronization aspects*. The advantage of this approach is that a given
timestamp format does not necessarily define the time standard (UTC / TAI),
and specifically does not necessarily define the leap second handling.

That means that a specification that uses a recommended timestamp format
should define the synchronization aspects, including leap second
considerations if such exist. See the following text in the draft:

   A specification that uses one of the recommended timestamp formats
   should also include a section on Synchronization Aspects...
   ...such as required accuracy, or leap second handling.


With that said, your point is well taken. In the next draft we will add
some more text that clarifies this point, including an example in Section 5.

Regards,
Tal.

On Sun, Sep 24, 2017 at 6:06 PM, Warner Losh  wrote:

>
>
> On Sun, Sep 24, 2017 at 7:37 AM, Tal Mizrahi 
> wrote:
>
>> Hi,
>>
>> We have revised the draft based on the comments received in IETF 99, and
>> based on the comments from Yaakov (thanks Yaakov).
>>
>> https://datatracker.ietf.org/doc/draft-mizrahi-intarea-packet-timestamps/
>>
>> The main changes compared to the previous version of the draft:
>> - We have extended the discussion about the factors that may affect the
>> choice of the timestamp format.
>> - A new section has been added, called "Timestamp Use Cases".
>> - The sychronization aspects have been separated from the timestamp
>> format, allowing the timestamp format to be independent of how time is
>> synchronized.
>>
>> Any further comments are welcome.
>>
>
> Section 4.1 says "Further considerations may be discussed in this
> section, such as required accuracy, or leap second handling." Yet none of
> the formats make any allowance for leap seconds. In NTP headers, leap
> second time stamps are marked with an out-of-band bit. In addition, all NTP
> time stamps are adjusted by the cumulative number of leap seconds, yet that
> relevant information is not included.PTP timestamps, on the other hand, are
> a count of TAI seconds since 1970, which have no adjustments.
>
> When I was doing time and frequency recovery, these differences weren't
> documented and many arguments ensued to get to the understanding of what's
> actually on the wire, what the auxiliary bits mean, etc. I'd rather see
> this document be explicit about such things rather than some vague hand
> wave that will be interpreted in many different ways leading to even more
> issues with leap seconds than we already have.
>
> Warner
>

--001a1140a9b0ffb59d0559fdcb57
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Warner,

Thanks for the feedback.


>Section 4.1 says "Further con=
siderations may be discussed in=C2=A0
>this section, such as r=
equired accuracy, or leap second handling."=C2=A0
>Yet no=
ne of the formats make any allowance for leap seconds.

Right. As I pointed out below, we have separated the *formats* fro=
m the *synchronization aspects*. The advantage of this approach is that a g=
iven timestamp format does not necessarily define the time standard (UTC / =
TAI), and specifically does not necessarily define the leap second handling=
.

That means that a specification that uses a reco=
mmended timestamp format should define the synchronization aspects, includi=
ng leap second considerations if such exist. See the following text in the =
draft:

=C2=A0 =C2=A0A specification that uses=
 one of the recommended timestamp formats
=C2=A0 =C2=A0should als=
o include a section on Synchronization Aspects... =C2=A0=C2=A0
=C2=A0 =
=C2=A0...such as required accuracy, or leap second handling.


With that said, your point is well taken. I=
n the next draft we will add some more text that clarifies this point, incl=
uding an example in Section 5.

Regards,
=
Tal.

O=
n Sun, Sep 24, 2017 at 6:06 PM, Warner Losh <imp@bsdimp.com> =
wrote:


On Sun, Sep 2=
4, 2017 at 7:37 AM, Tal Mizrahi <tal.mizrahi.phd@gmail.com>=
 wrote:
Hi,=C2=A0

We have revised the draft based on t=
he comments received in IETF 99, and based on the comments from Yaakov (tha=
nks Yaakov).


The main changes compared to the=
 previous version of the draft:
- We have extended the discussion=
 about the factors that may affect the choice of the timestamp format.
- A new section has been added, called "Timestamp Use Cases"=
;.
- The sychronization aspects have been separated from the time=
stamp format, allowing the timestamp format to be independent of how time i=
s synchronized.

Any further comments are welcome.<=
/div>

Section 4.1 says &=
quot;Further consid=
erations=C2=A0econd handling.=
" Yet none of the formats make any allowance for leap seconds. In NTP =
headers, leap second time stamps are marked with an out-of-band bit. In add=
ition, all NTP time stamps are adjusted by the cumulative number of leap se=
conds, yet that relevant information is not included.PTP timestamps, on the=
 other hand, are a count of TAI seconds since 1970, which have no adjustmen=
ts.
W=
hen I was doing time and frequency recovery, these differences weren't =
documented and many arguments ensued to get to the understanding of what=
9;s actually on the wire, what the auxiliary bits mean, etc. I'd rather=
 see this document be explicit about such things rather than some vague han=
d wave that will be interpreted in many different ways leading to even more=
 issues with leap seconds than we already have.

Warner
=






--001a1140a9b0ffb59d0559fdcb57--


From nobody Mon Sep 25 06:17:29 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 C9A1013430B for ; Mon, 25 Sep 2017 06:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bsdimp-com.20150623.gappssmtp.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 4o95_MnjIyZg for ; Mon, 25 Sep 2017 06:17:18 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9AB20134308 for ; Mon, 25 Sep 2017 06:17:18 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id v36so9713668ioi.1 for ; Mon, 25 Sep 2017 06:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CQfBW6eJGqnfgEXmNRdyTmoJYlLY2y1Ip0EfrOJUVsA=; b=F7jzKqsT8IuwMCN/kj/JwrsuYbZPl/MIdRsuumUBB8owGOxEou8W3S5/sAF5NSPyGJ Kr2xmelA2lUp8PO3i92BIm6S/obzwfNnEbHP8y64Oo+P4aJe2MxDf4OnxLHXbE3MslJY scuReCak9UbzQQWxPuhPm10allO4qjxGJqvKIpcfgDKbOA/hdYkb1Osazf/WeF1B17Cs jWsdvPVkiiX3jE3afGHtvpZyi0aCIlY/djEriLNK/z1woWrpNi3geaSfhGKqloCoQUCz jm23ErDI5Vaa9253oTm50WYS9BDwsVIrt3ALm7zo/22pW1Z+m8w4kWLfG3ECw2xyBQNU J09A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CQfBW6eJGqnfgEXmNRdyTmoJYlLY2y1Ip0EfrOJUVsA=; b=U7k9i2F/C6GT8FAPcPuPx2z8d8XCuzhqK6PzJY0DUvJ4as+6AjGBHVdzWLOBWXCvcg rhmlXol9sUbhN+jhVYHGYV3hlqWhT3qBhmlXSwGpqcbPsJqzBjnFliXX5AbOdTT5sTqb nPXZNWuz7UOn4CisDygzkrH8s+iBCqRYs5dl5E04MfNLGlC3lLXCPubjSEvN+seaFsoW uZb3UM/okklkLJjw6GNLoT6UivVRmWd8s3tlYcIsgQLfZYbBSgCMYczD/tP1dvaeNH66 Qf94iEDfyRHqW715XKiyTW95DFhDnnixQ5v2JA4utNA4TEPWHvbJ+i49NEZJdIPHdM6W zTcA==
X-Gm-Message-State: AHPjjUjdjKa0RL3FKoWjDOzHMieSDAZ0+2KRqJH/7EptDQtxNjeJTQ37 juppVJm5T+o1Hh15+eReP1zWQMDE9oq8GtsdnPrigg==
X-Google-Smtp-Source: AOwi7QDwg0eSBjp5O0nssNBsNpwlOOg98qYg69i8WK4EkweSMCwNmjOengzGzmgOFwNTSYM5Lw44aqAJa7/h20Q8R2w=
X-Received: by 10.107.185.7 with SMTP id j7mr9932416iof.221.1506345437608; Mon, 25 Sep 2017 06:17:17 -0700 (PDT)
MIME-Version: 1.0
Sender: wlosh@bsdimp.com
Received: by 10.79.2.194 with HTTP; Mon, 25 Sep 2017 06:17:16 -0700 (PDT)
X-Originating-IP: [50.253.99.174]
In-Reply-To: 
References:   
From: Warner Losh 
Date: Mon, 25 Sep 2017 07:17:16 -0600
X-Google-Sender-Auth: 3-g6k3yNQHuXecvbb0fBXqIbkm8
Message-ID: 
To: Tal Mizrahi 
Cc: tictoc@ietf.org, ntp@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c06d0fab7d838055a0360f0"
Archived-At: 
Subject: Re: [Ntp] Guidelines for Defining Packet Timestamps
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, 25 Sep 2017 13:17:22 -0000

--94eb2c06d0fab7d838055a0360f0
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 25, 2017 at 12:37 AM, Tal Mizrahi 
wrote:

> Hi Warner,
>
> Thanks for the feedback.
>
>
> >Section 4.1 says "Further considerations may be discussed in
> >this section, such as required accuracy, or leap second handling."
> >Yet none of the formats make any allowance for leap seconds.
>
> Right. As I pointed out below, we have separated the *formats* from the
> *synchronization aspects*. The advantage of this approach is that a given
> timestamp format does not necessarily define the time standard (UTC / TAI),
> and specifically does not necessarily define the leap second handling.
>

That's not an advantage by any means. If you don't know how to interpret
the data, it's useless. And leap seconds are part of the data, as much as
people want to ignore them. It's a flaw in the specification. You go to
great lengths to say that the PPT is seconds since a time in TAI. How you
count the seconds since the epoch is quite relevant. It's not just a
counter, but a corrected counter in NTP's case. And a counter and a
corrected counter are two very different things, since the math you can
safely do on them, and the meta data you need for some operations with them
differ. You can't escape that in defining the format because that's
critical to its use. And a corrected counter has ambiguities around the
leap second that are impossible to avoid without other metadata (NTP puts
that metadata into another bit of the NTP packet so you know, for example).
The details about the metadata likely can remain unspecified, but whether
or not leap seconds are swizzled in should not.


> That means that a specification that uses a recommended timestamp format
> should define the synchronization aspects, including leap second
> considerations if such exist. See the following text in the draft:
>
>    A specification that uses one of the recommended timestamp formats
>    should also include a section on Synchronization Aspects...
>    ...such as required accuracy, or leap second handling.
>
>
> With that said, your point is well taken. In the next draft we will add
> some more text that clarifies this point, including an example in Section 5.
>

As someone who has fought with formats being under specified, I can tell
right now that this will lead to trouble. You can't run away from the
Synchronization Aspects, at least not all of them. Having dealt with this
stuff for almost two decades in high precision time applications, and
having tried to separate out the two concepts to make things "cleaner" I
can attest from first hand experience that this is a mistake.

Warner


> Regards,
> Tal.
>
> On Sun, Sep 24, 2017 at 6:06 PM, Warner Losh  wrote:
>
>>
>>
>> On Sun, Sep 24, 2017 at 7:37 AM, Tal Mizrahi 
>> wrote:
>>
>>> Hi,
>>>
>>> We have revised the draft based on the comments received in IETF 99, and
>>> based on the comments from Yaakov (thanks Yaakov).
>>>
>>> https://datatracker.ietf.org/doc/draft-mizrahi-intarea-packe
>>> t-timestamps/
>>>
>>> The main changes compared to the previous version of the draft:
>>> - We have extended the discussion about the factors that may affect the
>>> choice of the timestamp format.
>>> - A new section has been added, called "Timestamp Use Cases".
>>> - The sychronization aspects have been separated from the timestamp
>>> format, allowing the timestamp format to be independent of how time is
>>> synchronized.
>>>
>>> Any further comments are welcome.
>>>
>>
>> Section 4.1 says "Further considerations may be discussed in this
>> section, such as required accuracy, or leap second handling." Yet none
>> of the formats make any allowance for leap seconds. In NTP headers, leap
>> second time stamps are marked with an out-of-band bit. In addition, all NTP
>> time stamps are adjusted by the cumulative number of leap seconds, yet that
>> relevant information is not included.PTP timestamps, on the other hand, are
>> a count of TAI seconds since 1970, which have no adjustments.
>>
>> When I was doing time and frequency recovery, these differences weren't
>> documented and many arguments ensued to get to the understanding of what's
>> actually on the wire, what the auxiliary bits mean, etc. I'd rather see
>> this document be explicit about such things rather than some vague hand
>> wave that will be interpreted in many different ways leading to even more
>> issues with leap seconds than we already have.
>>
>> Warner
>>
>
>

--94eb2c06d0fab7d838055a0360f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Sep 25, 2017 at 12:37 AM, Tal Mizrahi <tal.mizrahi.phd=
@gmail.com> wrote:
Hi Warner,

Thanks for the feedback.


>Section 4.1 says "Fu=
rther considerations may be discussed in=C2=A0
>this section, =
such as required accuracy, or leap second handling."=C2=A0
&=
gt;Yet none of the formats make any allowance for leap seconds.

Right. As I pointed out below, we have separated t=
he *formats* from the *synchronization aspects*. The advantage of this appr=
oach is that a given timestamp format does not necessarily define the time =
standard (UTC / TAI), and specifically does not necessarily define the leap=
 second handling.

That's no=
t an advantage by any means. If you don't know how to interpret the dat=
a, it's useless. And leap seconds are part of the data, as much as peop=
le want to ignore them. It's a flaw in the specification. You go to gre=
at lengths to say that the PPT is seconds since a time in TAI. How you coun=
t the seconds since the epoch is quite relevant. It's not just a counte=
r, but a corrected counter in NTP's case. And a counter and a corrected=
 counter are two very different things, since the math you can safely do on=
 them, and the meta data you need for some operations with them differ. You=
 can't escape that in defining the format because that's critical t=
o its use. And a corrected counter has ambiguities around the leap second t=
hat are impossible to avoid without other metadata (NTP puts that metadata =
into another bit of the NTP packet so you know, for example). The details a=
bout the metadata likely can remain unspecified, but whether or not leap se=
conds are swizzled in should not.
=C2=A0
That means that a specification that us=
es a recommended timestamp format should define the synchronization aspects=
, including leap second considerations if such exist. See the following tex=
t in the draft:

=C2=A0 =C2=A0A specification =
that uses one of the recommended timestamp formats
=C2=A0 =C2=A0s=
hould also include a section on Synchronization Aspects... =C2=A0=C2=A0
=
=C2=A0 =C2=A0...such as required accuracy, or leap second handling.


With that said, your point is well t=
aken. In the next draft we will add some more text that clarifies this poin=
t, including an example in Section 5.

As someone who has fought with formats being under specified, I can =
tell right now that this will lead to trouble. You can't run away from =
the Synchronization Aspects, at least not all of them. Having dealt with th=
is stuff for almost two decades in high precision time applications, and ha=
ving tried to separate out the two concepts to make things "cleaner&qu=
ot; I can attest from first hand experience that this is a mistake.

Warner
=C2=A0
Regards,
Tal.

On Sun, Sep 24, 2017 at 6:06 PM, Warner Losh <=
imp@bsdimp.com><=
/span> wrote:


On Sun, Sep 24, 2=
017 at 7:37 AM, Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
Hi,=C2=A0

We have revised the draft based on the c=
omments received in IETF 99, and based on the comments from Yaakov (thanks =
Yaakov).


The main changes compared to the pre=
vious version of the draft:
- We have extended the discussion abo=
ut the factors that may affect the choice of the timestamp format.
- A new section has been added, called "Timestamp Use Cases".
- The sychronization aspects have been separated from the timestam=
p format, allowing the timestamp format to be independent of how time is sy=
nchronized.

Any further comments are welcome.

Section 4.1 says "=
;Further considerat=
ions=C2=A0ma=
y be discussed in this section, such as required accuracy, or leap s=
econd handling.&quo=
t; Yet none of the formats make any allowance for leap seconds. In NTP head=
ers, leap second time stamps are marked with an out-of-band bit. In additio=
n, all NTP time stamps are adjusted by the cumulative number of leap second=
s, yet that relevant information is not included.PTP timestamps, on the oth=
er hand, are a count of TAI seconds since 1970, which have no adjustments.<=
/span>
When =
I was doing time and frequency recovery, these differences weren't docu=
mented and many arguments ensued to get to the understanding of what's =
actually on the wire, what the auxiliary bits mean, etc. I'd rather see=
 this document be explicit about such things rather than some vague hand wa=
ve that will be interpreted in many different ways leading to even more iss=
ues with leap seconds than we already have.

Warner








--94eb2c06d0fab7d838055a0360f0--


From nobody Mon Sep 25 08:19: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 38E7B1344A2; Mon, 25 Sep 2017 08:19:44 -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 vinJx4NXwsk1; Mon, 25 Sep 2017 08:19:42 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 28278134496; Mon, 25 Sep 2017 08:19:42 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id j126so7401447oia.10; Mon, 25 Sep 2017 08:19:42 -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=4el9TvFZRAcNeOUI+/mJy+DhnpGz+yGE/2Guz3ybHz8=; b=LFpLHRoWw/u7Ue/ne+tKz/rd+19yRxvf0gWUO2eM9ZVCX7OqamPcf7f9vWSusCNAEx oJA9i9LPDqFGYmiZTxZrKvP1ZP1n3iBBzyYVmaEW7aW7xvXisik7p3lXutZphUB8wDdS a7Kf13DJMAdnKdB5dvn6r2/F0hkBSBWf3oqGRN13luCXG46+fAXeh3PWVDtN/ztu5i2B 9UC9W2O+D+n/+q086rLm3Mb7hZeXwfkF5ou0hQTMupqloDZBwdv8CBUwZxS4X6VLh7bP +U1W6PCAl82wmO4sDsejssNbtbqnIHGGvFtIJI+13AAjGk+IXthSb5uBKTtK+F4GjNPw DpMg==
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=4el9TvFZRAcNeOUI+/mJy+DhnpGz+yGE/2Guz3ybHz8=; b=iv3dEivPxT3tkKW02Td+P8Oo2nCKZKMXx5v6n2whrm7ztkv2w71rXvgV00BMC5074X dKubo4eCnWv4+tGEe/NyoWaGGgqNRZNdntZeuYOySn3BSu3JVRMkOaWOh0n99BPslVQ7 /1Hi++IfYHUuiw1avqqwT0pLZBDifFOtjfnQMw2bG91CAKyEEAB7+d5mdqtXgG9hfUq8 A2kDbncYA8FoCJHayPkA3SgWzKqcVpEqjkeVPnCd7GxRbl9qRGhVhpVl6K66p39O3KVM gwUXql7Dla8jIXAijcg76WVMt6eUBhI1qXOTE1RmDxkgiNlDXLWiFs9BpYTofoi3u3Vm WQCw==
X-Gm-Message-State: AHPjjUho72YYKWcKzUfp4+QKzViGcU1+U6dpH0V2y7MGQDJkr3x2jFUz GWocytY/Ys5QfKek/C4HklSyyBRpJQBRxJ/IqEc=
X-Google-Smtp-Source: AOwi7QDtXVymwhxKM1sSoj1U3pen1Qez2mtIBAU3KERPHzukrDgg2KRVtEALvZuSbZ344Bty2LT460sXMSHxIKHbgj8=
X-Received: by 10.157.48.8 with SMTP id d8mr464755otc.59.1506352781573; Mon, 25 Sep 2017 08:19:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.168.181.200 with HTTP; Mon, 25 Sep 2017 08:19:41 -0700 (PDT)
In-Reply-To: 
References:  
From: Tal Mizrahi 
Date: Mon, 25 Sep 2017 18:19:41 +0300
Message-ID: 
To: Rodney Cummings 
Cc: "tictoc@ietf.org" , "ntp@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113e174073c22c055a05166c"
Archived-At: 
Subject: Re: [Ntp] [TICTOC] Guidelines for Defining Packet Timestamps
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, 25 Sep 2017 15:19:44 -0000

--001a113e174073c22c055a05166c
Content-Type: text/plain; charset="UTF-8"

Hi Rodney,

Thanks for the feedback.
We will certainly take these notes into consideration in the next version.

Can you please elaborate which protocols use the 80-bit timestamp format
(other than PTP, obviously)?

Thanks,
Tal.


On Mon, Sep 25, 2017 at 6:01 PM, Rodney Cummings 
wrote:

> Hi Tal,
>
> This is an excellent draft. I have a couple of suggestions.
>
> 1. Add the PTP 80-bit Timestamp, since there are protocols using that as
> well, some with hardware support.
>
> 2. In section 4, add informative text to explain one of the benefits of
> specifying a small set of fixed format specifications: hardware support.
> The lower down in the interface stack that timestamping occurs, the more
> accurate and precise the timestamp. This is well known for PTP, for which
> timestamping is often done at the MAC or PHY level. Hardware support is
> potentially a reason to avoid the control field mentioned in section 7,
> because hardware typically cannot support "any" format... ideally this RFC
> will narrow it down to 2-3 at most.
>
> Rodney
>
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
> Sent: Sunday, September 24, 2017 8:38 AM
> To: tictoc@ietf.org; ntp@ietf.org
> Subject: [TICTOC] Guidelines for Defining Packet Timestamps
>
> Hi,
>
> We have revised the draft based on the comments received in IETF 99, and
> based on the comments from Yaakov (thanks Yaakov).
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_draft-2Dmizrahi-2Dintarea-
> 2Dpacket-2Dtimestamps_&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZ
> uIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=
> yUZsj6L0ib9J4wu3kPNa1OQJK4MJPBl2vMca6Rpvx_Q&s=xdFj3xTP-9EZqma_
> 84T6eWQ0p0VlwMrdXil6FFU3FW0&e=
>
> The main changes compared to the previous version of the draft:
> - We have extended the discussion about the factors that may affect the
> choice of the timestamp format.
> - A new section has been added, called "Timestamp Use Cases".
> - The sychronization aspects have been separated from the timestamp
> format, allowing the timestamp format to be independent of how time is
> synchronized.
>
> Any further comments are welcome.
>
> Cheers,
> Tal, Joachim, and Al.
>

--001a113e174073c22c055a05166c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Rodney,

Thanks for the feedback.=C2=
=A0
We will certainly take these notes into consideration in the =
next version.

Can you please elaborate which proto=
cols use the 80-bit timestamp format (other than PTP, obviously)?

Thanks,
Tal.


On Mon, Sep 25, 2017 at 6:0=
1 PM, Rodney Cummings <rodney.cummings@ni.com> wrote:
Hi Tal,



This is an excellent draft. I have a couple of suggestions.



1. Add the PTP 80-bit Timestamp, since there are protocols using that as we=
ll, some with hardware support.



2. In section 4, add informative text to explain one of the benefits of spe=
cifying a small set of fixed format specifications: hardware support. The l=
ower down in the interface stack that timestamping occurs, the more accurat=
e and precise the timestamp. This is well known for PTP, for which timestam=
ping is often done at the MAC or PHY level. Hardware support is potentially=
 a reason to avoid the control field mentioned in section 7, because hardwa=
re typically cannot support "any" format... ideally this RFC will=
 narrow it down to 2-3 at most.



Rodney



From: TICTOC [mailto:tictoc-boun=
ces@ietf.org] On Behalf Of Tal Mizrahi

Sent: Sunday, September 24, 2017 8:38 AM

To: tictoc@ietf.org; ntp@ietf.org

Subject: [TICTOC] Guidelines for Defining Packet Timestamps



Hi,=C2=A0



We have revised the draft based on the comments received in IETF 99, and ba=
sed on the comments from Yaakov (thanks Yaakov).



https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dmizra=
hi-2Dintarea-2Dpacket-2Dtimestamps_&d=3DDwMFaQ&c=3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7Cb=
YhFt24DPjt3lJuupswWYdnboKbZ8k&m=3DyUZsj6L0ib9J4wu3kPNa1OQJK4M=
JPBl2vMca6Rpvx_Q&s=3DxdFj3xTP-9EZqma_84T6eWQ0p0VlwMrdXil=
6FFU3FW0&e=3D




The main changes compared to the previous version of the draft:

- We have extended the discussion about the factors that may affect the cho=
ice of the timestamp format.

- A new section has been added, called "Timestamp Use Cases".

- The sychronization aspects have been separated from the timestamp format,=
 allowing the timestamp format to be independent of how time is synchronize=
d.



Any further comments are welcome.



Cheers,

Tal, Joachim, and Al.





--001a113e174073c22c055a05166c--


From nobody Mon Sep 25 08:31: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 E8B87132E24; Mon, 25 Sep 2017 08:31:43 -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 D-9B8eLCAj4R; Mon, 25 Sep 2017 08:31:41 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 57365132025; Mon, 25 Sep 2017 08:31:41 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id v188so7449198oia.5; Mon, 25 Sep 2017 08:31:41 -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=3XSGahnNk8LqtwkjHvOypQephds55kbSqTIJBx2qlVU=; b=KptjfK/QvpYjnBZ95aby6LSSGxIwWCKQGWE8zFeF3gGhiak26YYXFc9wlMCPIp9DC3 R9oB2uFwgbHTUpo6hfvBdHK+DuDHRMfz+XpwakVJdxta9uA4LHnXWcMg1w1Oyy2O/OXk WpKDFK+Bxv10U01G1m/0GaeFj9PQ3Z9vnvocdcGtZO1VnvwFThCkFAUQDOXSV4nYpvd9 9v/R3NJtAx41C2hMkQ1u/xA7+O6PrTOVCjCSIhgrWo9qe7FfftzABC+pqy6N9nzPciub Nl/kC8osUMq3/FsgC399jPA4xk7bAbe1khSCd9G9yS3FHVNE8/1p7gsyzQJfTuMpCJ6V L/cg==
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=3XSGahnNk8LqtwkjHvOypQephds55kbSqTIJBx2qlVU=; b=Y5khUJ7KIC6cKNH/vqrilh+Ys1BXO99pFHF7p4SA5yhn+yw3prRv2iGatzAw7nuU7I R0DIzRho+eedG3V5VGU8lM84+Rld+4LXLX1NbqyeNCIZ5NyK/AhQFi4tV2Iu2202ovnW nAekSfQ4ZjPaCg+CDEOs+CTZSW1TOLlj5cOY/pzWVhFmfm6U2AsV3Vda4cxyGTAVQFew Timly9hmwaOuZ7DRdW5bL1slHn2K/WSNtuxvI41pGV0qSa03omPz7zT3Z4NBkbZCJapt W94JgLDdwkXwSvqrYnPUD7CKtMR3seG6P1cY72a5D/DBXU9ZKC9Pi6S8hqxqvK3gCmP+ SVSA==
X-Gm-Message-State: AHPjjUgyIDdWEUBCrWJxqFkpWPTe9LTHBG8cuicbqepWwnam+nRR0N9Y nlsbZ1yBGAex4FIh01JQK8qi6/5p5nzIuDbGOmY=
X-Google-Smtp-Source: AOwi7QCNvslHF/pIO7+0ZTD1DL/TGGzEkq13X7ogR/VVHV7TRagorUbwEfHiA17QpNqS6UlvJsXvLiq3fR8EqGGZ3f4=
X-Received: by 10.202.87.77 with SMTP id l74mr10113669oib.119.1506353500617; Mon, 25 Sep 2017 08:31:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.168.181.200 with HTTP; Mon, 25 Sep 2017 08:31:39 -0700 (PDT)
In-Reply-To: 
References:    
From: Tal Mizrahi 
Date: Mon, 25 Sep 2017 18:31:39 +0300
Message-ID: 
To: Warner Losh 
Cc: tictoc@ietf.org, ntp@ietf.org
Content-Type: multipart/alternative; boundary="001a113ad4344f897a055a054145"
Archived-At: 
Subject: Re: [Ntp] Guidelines for Defining Packet Timestamps
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, 25 Sep 2017 15:31:44 -0000

--001a113ad4344f897a055a054145
Content-Type: text/plain; charset="UTF-8"

Hi Warner,

We are in full agreement that any considerations relating to the leap
second should be defined.

I believe the main question here is whether leap second considerations
should be defined in the recommended timestamp formats, or in the protocols
that use them.
One thing to remember is that this draft is intended to be generic, so that
timestamp formats will be applicable to many different protocols such as
OWAMP, TWAMP, TRILL loss/delay, MPLS loss/delay, and of course NTP.
Therefore, there may be an advantage to having a common timestamp format
that is sometimes used with respect to TAI (no leap seconds), and sometimes
used with respect to UTC (leap second considerations are required).

Whether leap second considerations are included in the timestamp format, or
in the protocol that uses it, either way I fully agree that such
considerations should be defined.

Since there are advantages on either way, I would be happy to hear from
other people on the list what they believe would be the best approach here.

Cheers,
Tal.


On Mon, Sep 25, 2017 at 4:17 PM, Warner Losh  wrote:

>
>
> On Mon, Sep 25, 2017 at 12:37 AM, Tal Mizrahi 
> wrote:
>
>> Hi Warner,
>>
>> Thanks for the feedback.
>>
>>
>> >Section 4.1 says "Further considerations may be discussed in
>> >this section, such as required accuracy, or leap second handling."
>> >Yet none of the formats make any allowance for leap seconds.
>>
>> Right. As I pointed out below, we have separated the *formats* from the
>> *synchronization aspects*. The advantage of this approach is that a given
>> timestamp format does not necessarily define the time standard (UTC / TAI),
>> and specifically does not necessarily define the leap second handling.
>>
>
> That's not an advantage by any means. If you don't know how to interpret
> the data, it's useless. And leap seconds are part of the data, as much as
> people want to ignore them. It's a flaw in the specification. You go to
> great lengths to say that the PPT is seconds since a time in TAI. How you
> count the seconds since the epoch is quite relevant. It's not just a
> counter, but a corrected counter in NTP's case. And a counter and a
> corrected counter are two very different things, since the math you can
> safely do on them, and the meta data you need for some operations with them
> differ. You can't escape that in defining the format because that's
> critical to its use. And a corrected counter has ambiguities around the
> leap second that are impossible to avoid without other metadata (NTP puts
> that metadata into another bit of the NTP packet so you know, for example).
> The details about the metadata likely can remain unspecified, but whether
> or not leap seconds are swizzled in should not.
>
>
>> That means that a specification that uses a recommended timestamp format
>> should define the synchronization aspects, including leap second
>> considerations if such exist. See the following text in the draft:
>>
>>    A specification that uses one of the recommended timestamp formats
>>    should also include a section on Synchronization Aspects...
>>    ...such as required accuracy, or leap second handling.
>>
>>
>> With that said, your point is well taken. In the next draft we will add
>> some more text that clarifies this point, including an example in Section 5.
>>
>
> As someone who has fought with formats being under specified, I can tell
> right now that this will lead to trouble. You can't run away from the
> Synchronization Aspects, at least not all of them. Having dealt with this
> stuff for almost two decades in high precision time applications, and
> having tried to separate out the two concepts to make things "cleaner" I
> can attest from first hand experience that this is a mistake.
>
> Warner
>
>
>> Regards,
>> Tal.
>>
>> On Sun, Sep 24, 2017 at 6:06 PM, Warner Losh  wrote:
>>
>>>
>>>
>>> On Sun, Sep 24, 2017 at 7:37 AM, Tal Mizrahi 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> We have revised the draft based on the comments received in IETF 99,
>>>> and based on the comments from Yaakov (thanks Yaakov).
>>>>
>>>> https://datatracker.ietf.org/doc/draft-mizrahi-intarea-packe
>>>> t-timestamps/
>>>>
>>>> The main changes compared to the previous version of the draft:
>>>> - We have extended the discussion about the factors that may affect the
>>>> choice of the timestamp format.
>>>> - A new section has been added, called "Timestamp Use Cases".
>>>> - The sychronization aspects have been separated from the timestamp
>>>> format, allowing the timestamp format to be independent of how time is
>>>> synchronized.
>>>>
>>>> Any further comments are welcome.
>>>>
>>>
>>> Section 4.1 says "Further considerations may be discussed in this
>>> section, such as required accuracy, or leap second handling." Yet none
>>> of the formats make any allowance for leap seconds. In NTP headers, leap
>>> second time stamps are marked with an out-of-band bit. In addition, all NTP
>>> time stamps are adjusted by the cumulative number of leap seconds, yet that
>>> relevant information is not included.PTP timestamps, on the other hand, are
>>> a count of TAI seconds since 1970, which have no adjustments.
>>>
>>> When I was doing time and frequency recovery, these differences weren't
>>> documented and many arguments ensued to get to the understanding of what's
>>> actually on the wire, what the auxiliary bits mean, etc. I'd rather see
>>> this document be explicit about such things rather than some vague hand
>>> wave that will be interpreted in many different ways leading to even more
>>> issues with leap seconds than we already have.
>>>
>>> Warner
>>>
>>
>>
>

--001a113ad4344f897a055a054145
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Warner,

We are in full agreement tha=
t any considerations relating to the leap second should be defined.

I believe the main question here is whether leap second c=
onsiderations should be defined in the recommended timestamp formats, or in=
 the protocols that use them.
One thing to remember is that =
this draft is intended to be generic, so that timestamp formats will be app=
licable to many different protocols such as OWAMP, TWAMP, TRILL loss/delay,=
 MPLS loss/delay, and of course NTP. Therefore, there may be an advantage t=
o having a common timestamp format that is sometimes used with respect to T=
AI (no leap seconds), and sometimes used with respect to UTC (leap second c=
onsiderations are required).

Whether leap se=
cond considerations are included in the timestamp format, or in the protoco=
l that uses it, either way I fully agree that such considerations should be=
 defined.

Since there are advantages on either way=
, I would be happy to hear from other people on the list what they believe =
would be the best approach here.

Cheers,
Tal.


On Mon, Sep 25, 2017 at 4:17 PM, Warner Losh <imp@bsdimp.com=
> wrote:
<=
br>

On Mon, Sep 25, 2017 at 12:37 AM, Tal Mizrahi <tal.mizrahi.phd@=
gmail.com> wrote:
Hi Warner,

Thanks for the feedback.
=



>Section 4.1 says "Further consi=
derations may be discussed in=C2=A0
>this section, such as req=
uired accuracy, or leap second handling."=C2=A0
>Yet none=
 of the formats make any allowance for leap seconds.

Right. As I pointed out below, we have separated the *formats=
* from the *synchronization aspects*. The advantage of this approach is tha=
t a given timestamp format does not necessarily define the time standard (U=
TC / TAI), and specifically does not necessarily define the leap second han=
dling.

That's not an=
 advantage by any means. If you don't know how to interpret the data, i=
t's useless. And leap seconds are part of the data, as much as people w=
ant to ignore them. It's a flaw in the specification. You go to great l=
engths to say that the PPT is seconds since a time in TAI. How you count th=
e seconds since the epoch is quite relevant. It's not just a counter, b=
ut a corrected counter in NTP's case. And a counter and a corrected cou=
nter are two very different things, since the math you can safely do on the=
m, and the meta data you need for some operations with them differ. You can=
't escape that in defining the format because that's critical to it=
s use. And a corrected counter has ambiguities around the leap second that =
are impossible to avoid without other metadata (NTP puts that metadata into=
 another bit of the NTP packet so you know, for example). The details about=
 the metadata likely can remain unspecified, but whether or not leap second=
s are swizzled in should not.
=C2=A0
That means that a specificat=
ion that uses a recommended timestamp format should define the synchronizat=
ion aspects, including leap second considerations if such exist. See the fo=
llowing text in the draft:

=C2=A0 =C2=A0A spe=
cification that uses one of the recommended timestamp formats
=C2=
=A0 =C2=A0should also include a section on Synchronization Aspects... =C2=
=A0=C2=A0
=C2=A0 =C2=A0...such as required accuracy, or leap second hand=
ling.


With that said, your po=
int is well taken. In the next draft we will add some more text that clarif=
ies this point, including an example in Section 5.
=


As someone who has fought with formats being und=
er specified, I can tell right now that this will lead to trouble. You can&=
#39;t run away from the Synchronization Aspects, at least not all of them. =
Having dealt with this stuff for almost two decades in high precision time =
applications, and having tried to separate out the two concepts to make thi=
ngs "cleaner" I can attest from first hand experience that this i=
s a mistake.

<=
/div>
Warner
=C2=A0
Regards,
Tal.

=
On Sun, Sep 24, 2017 at 6:06 PM, Warner Losh <imp@bsdimp.com> =
wrote:

Section 4.1 says "Further considerations=C2=
=A0may be di=
scussed in this section, such as required accuracy, or leap second handling." Yet =
none of the formats make any allowance for leap seconds. In NTP headers, le=
ap second time stamps are marked with an out-of-band bit. In addition, all =
NTP time stamps are adjusted by the cumulative number of leap seconds, yet =
that relevant information is not included.PTP timestamps, on the other hand=
, are a count of TAI seconds since 1970, which have no adjustments.<=
/div>

When I was d=
oing time and frequency recovery, these differences weren't documented =
and many arguments ensued to get to the understanding of what's actuall=
y on the wire, what the auxiliary bits mean, etc. I'd rather see this d=
ocument be explicit about such things rather than some vague hand wave that=
 will be interpreted in many different ways leading to even more issues wit=
h leap seconds than we already have.

Warner











--001a113ad4344f897a055a054145--


From nobody Mon Sep 25 10:32:04 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 A423013449D; Mon, 25 Sep 2017 08:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.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 7NLRNT3Q_Flt; Mon, 25 Sep 2017 08:01:42 -0700 (PDT)
Received: from mx0b-00010702.pphosted.com (mx0b-00010702.pphosted.com [148.163.158.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68059133087; Mon, 25 Sep 2017 08:01:42 -0700 (PDT)
Received: from pps.filterd (m0098779.ppops.net [127.0.0.1]) by mx0b-00010702.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8PF197I027943; Mon, 25 Sep 2017 10:01:40 -0500
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0118.outbound.protection.outlook.com [207.46.163.118]) by mx0b-00010702.pphosted.com with ESMTP id 2d65nknm0v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Sep 2017 10:01:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i3TsFRWmUnBg5T9ulVPRqSv0DYIWk8fsvZatxDO+gHU=; b=ZepTGZwYQb6L8V9uFszfDXkonVFyKXrQybvBWB+4sp58guy0D4H3fiP0ynZRciLqyVwZMnxXzeztBiNu0tavpexCeAuv32xYIaTiMSh2c5JKay/IAZq6HEhN2ZqWXedou8OUOiRJ+p7AKloHwgwzCxZIE039N4hU+hlADJx/tjU=
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com (10.160.219.156) by DM2PR0401MB1392.namprd04.prod.outlook.com (10.160.221.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 25 Sep 2017 15:01:37 +0000
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::b172:affa:cf1d:384e]) by DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::b172:affa:cf1d:384e%18]) with mapi id 15.20.0077.011; Mon, 25 Sep 2017 15:01:37 +0000
From: Rodney Cummings 
To: Tal Mizrahi , "tictoc@ietf.org" , "ntp@ietf.org" 
Thread-Topic: [TICTOC] Guidelines for Defining Packet Timestamps
Thread-Index: AQHTNTpMvNLEW+VMsEedh0vQp3P1WaLFseJQ
Date: Mon, 25 Sep 2017 15:01:37 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.164.62.43]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0401MB1392; 6:GuDHHY15HbPWEuySduhZNeEqyjVLOMEm0qonKJi6xHNIAtdHOFW/caZ8zQ+tcnE5XmXwlKf/lbrux8jBZitlCkLNn4hsk/Siprb/F/1q9H96NO6tS/P/3L7uRQuc3WMN7ndJD7Y4b4XL3Jf2yMq32DHLc1hr859OS7qXCX6qBba9SEoNIU4uT77sPoakXcLzIR1K+ghXdSsoYWz4tAt/XBxOvjvnEr5mXmNRFTEvMru6Zu1pjg5DnNu5Yxsw8pKgBxgLvKDpArmUrjJPaEqDQQT3tdwu8UZU8TDjWKDg1lighymccsGjspi/rbIgmwS7rCJMPjM/18esURJ/Au87dg==; 5:G9lpv4wlbnN5DEnRJI2SpGv9HdaCG8blm3P8odABqcH6/YrdSBcsf/I0KN+u2hLVxeqB5gASCcIzXHpnpvApVFb3A7uJ62GcyTqv4sYLHiKpxrnY8exCOPAhsntlUaVPO1IihdyzQAYkdCFWEC6vGQ==; 24:7Z0E1BxgOTwDcjdgvUELuqBHZW8L5jHLNFona/EDB8GyJTOi8wLgwpXAKrWDhMpWuLd9z6RjlmemgPjpC0xa8g5coOwIaEh3rqUUxRlM208=; 7:uxi1+G1N0T9fGIaiqKKwD+nRLu1nb1MQ8s5JfKxJR3mJaGpwpXAaib/LAIvbWouj6e3k0hEI6JyFLMMU2yeMygnVjnMI6qo+CITfZ3h5OfJdJgMTvJWIAD1z9+e+l/j3Qo8Yw9IDAagD07h6zdDlCqnNjMmZNcLtLSvdYsCJ2jvQBWiifvtkfXX7C8ZvaCOb5YV6BTH2fK3oxoHS66KJh9zlCkL1VyGve5UBfzHYQC4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: e1a82468-ceb5-4001-329a-08d504265222
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR0401MB1392; 
x-ms-traffictypediagnostic: DM2PR0401MB1392:
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0401MB1392; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0401MB1392; 
x-forefront-prvs: 04410E544A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(377454003)(199003)(74316002)(316002)(3846002)(102836003)(2950100002)(2201001)(6116002)(189998001)(14454004)(229853002)(7696004)(575784001)(5250100002)(966005)(2906002)(86362001)(5660300001)(7736002)(97736004)(305945005)(66066001)(2501003)(33656002)(106356001)(6436002)(99286003)(101416001)(478600001)(105586002)(25786009)(81166006)(110136005)(6306002)(2900100001)(3280700002)(81156014)(9686003)(8676002)(55016002)(53936002)(68736007)(39060400002)(76176999)(3660700001)(50986999)(8936002)(6506006)(54356999)(53546010)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0401MB1392; H:DM2PR0401MB1389.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ni.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 15:01:37.4159 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0401MB1392
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-25_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709250228
Archived-At: 
X-Mailman-Approved-At: Mon, 25 Sep 2017 10:32:03 -0700
Subject: Re: [Ntp] [TICTOC] Guidelines for Defining Packet Timestamps
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, 25 Sep 2017 15:01:49 -0000

SGkgVGFsLA0KDQpUaGlzIGlzIGFuIGV4Y2VsbGVudCBkcmFmdC4gSSBoYXZlIGEgY291cGxlIG9m
IHN1Z2dlc3Rpb25zLg0KDQoxLiBBZGQgdGhlIFBUUCA4MC1iaXQgVGltZXN0YW1wLCBzaW5jZSB0
aGVyZSBhcmUgcHJvdG9jb2xzIHVzaW5nIHRoYXQgYXMgd2VsbCwgc29tZSB3aXRoIGhhcmR3YXJl
IHN1cHBvcnQuDQoNCjIuIEluIHNlY3Rpb24gNCwgYWRkIGluZm9ybWF0aXZlIHRleHQgdG8gZXhw
bGFpbiBvbmUgb2YgdGhlIGJlbmVmaXRzIG9mIHNwZWNpZnlpbmcgYSBzbWFsbCBzZXQgb2YgZml4
ZWQgZm9ybWF0IHNwZWNpZmljYXRpb25zOiBoYXJkd2FyZSBzdXBwb3J0LiBUaGUgbG93ZXIgZG93
biBpbiB0aGUgaW50ZXJmYWNlIHN0YWNrIHRoYXQgdGltZXN0YW1waW5nIG9jY3VycywgdGhlIG1v
cmUgYWNjdXJhdGUgYW5kIHByZWNpc2UgdGhlIHRpbWVzdGFtcC4gVGhpcyBpcyB3ZWxsIGtub3du
IGZvciBQVFAsIGZvciB3aGljaCB0aW1lc3RhbXBpbmcgaXMgb2Z0ZW4gZG9uZSBhdCB0aGUgTUFD
IG9yIFBIWSBsZXZlbC4gSGFyZHdhcmUgc3VwcG9ydCBpcyBwb3RlbnRpYWxseSBhIHJlYXNvbiB0
byBhdm9pZCB0aGUgY29udHJvbCBmaWVsZCBtZW50aW9uZWQgaW4gc2VjdGlvbiA3LCBiZWNhdXNl
IGhhcmR3YXJlIHR5cGljYWxseSBjYW5ub3Qgc3VwcG9ydCAiYW55IiBmb3JtYXQuLi4gaWRlYWxs
eSB0aGlzIFJGQyB3aWxsIG5hcnJvdyBpdCBkb3duIHRvIDItMyBhdCBtb3N0Lg0KDQpSb2RuZXkN
Cg0KRnJvbTogVElDVE9DIFttYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBUYWwgTWl6cmFoaQ0KU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTcgODozOCBB
TQ0KVG86IHRpY3RvY0BpZXRmLm9yZzsgbnRwQGlldGYub3JnDQpTdWJqZWN0OiBbVElDVE9DXSBH
dWlkZWxpbmVzIGZvciBEZWZpbmluZyBQYWNrZXQgVGltZXN0YW1wcw0KDQpIaSzCoA0KDQpXZSBo
YXZlIHJldmlzZWQgdGhlIGRyYWZ0IGJhc2VkIG9uIHRoZSBjb21tZW50cyByZWNlaXZlZCBpbiBJ
RVRGIDk5LCBhbmQgYmFzZWQgb24gdGhlIGNvbW1lbnRzIGZyb20gWWFha292ICh0aGFua3MgWWFh
a292KS4NCg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz
LTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRtaXpyYWhpLTJEaW50YXJlYS0y
RHBhY2tldC0yRHRpbWVzdGFtcHNfJmQ9RHdNRmFRJmM9SV8wWXdvS3k3ejVMTVRWZHlPNllDaUUy
dXpJMWpqWlp1SVBlbGNTaml4QSZyPVdBNzFzZjJvN0R3N0NiWWhGdDI0RFBqdDNsSnV1cHN3V1lk
bmJvS2JaOGsmbT15VVpzajZMMGliOUo0d3Uza1BOYTFPUUpLNE1KUEJsMnZNY2E2UnB2eF9RJnM9
eGRGajN4VFAtOUVacW1hXzg0VDZlV1EwcDBWbHdNcmRYaWw2RkZVM0ZXMCZlPQ0KDQpUaGUgbWFp
biBjaGFuZ2VzIGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoZSBkcmFmdDoN
Ci0gV2UgaGF2ZSBleHRlbmRlZCB0aGUgZGlzY3Vzc2lvbiBhYm91dCB0aGUgZmFjdG9ycyB0aGF0
IG1heSBhZmZlY3QgdGhlIGNob2ljZSBvZiB0aGUgdGltZXN0YW1wIGZvcm1hdC4NCi0gQSBuZXcg
c2VjdGlvbiBoYXMgYmVlbiBhZGRlZCwgY2FsbGVkICJUaW1lc3RhbXAgVXNlIENhc2VzIi4NCi0g
VGhlIHN5Y2hyb25pemF0aW9uIGFzcGVjdHMgaGF2ZSBiZWVuIHNlcGFyYXRlZCBmcm9tIHRoZSB0
aW1lc3RhbXAgZm9ybWF0LCBhbGxvd2luZyB0aGUgdGltZXN0YW1wIGZvcm1hdCB0byBiZSBpbmRl
cGVuZGVudCBvZiBob3cgdGltZSBpcyBzeW5jaHJvbml6ZWQuDQoNCkFueSBmdXJ0aGVyIGNvbW1l
bnRzIGFyZSB3ZWxjb21lLg0KDQpDaGVlcnMsDQpUYWwsIEpvYWNoaW0sIGFuZCBBbC4NCg==


From nobody Mon Sep 25 10:32:11 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 D6770134524; Mon, 25 Sep 2017 10:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.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 cZQ8RHR_EzLM; Mon, 25 Sep 2017 10:21:44 -0700 (PDT)
Received: from mx0b-00010702.pphosted.com (mx0a-00010702.pphosted.com [148.163.156.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2C413450A; Mon, 25 Sep 2017 10:21:44 -0700 (PDT)
Received: from pps.filterd (m0098780.ppops.net [127.0.0.1]) by mx0a-00010702.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8PHKVMX001909; Mon, 25 Sep 2017 12:21:41 -0500
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0055.outbound.protection.outlook.com [216.32.180.55]) by mx0a-00010702.pphosted.com with ESMTP id 2d67v2pp5p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Sep 2017 12:21:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KMVsGSNdYNV8GkE9OTBhbxCzCb/yL//vfgIrhjry7a4=; b=SQaE8k0nR0+Kbm4EEHQEijPyCZgywLFdSvYWnHrzhluffBKR8zxjkhShwkJ0uSjvShWZztr3gysl3vapq57oKpCxa/1dhlbRqJ/s6OMc5SYQtr4ArNFduFZkzPKtf/iFO/IHbS+JRJasGBry9lA3xFgFCvxX+hG6wFO/09SWrhc=
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com (10.160.219.156) by DM2PR0401MB1391.namprd04.prod.outlook.com (10.160.221.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 25 Sep 2017 17:21:40 +0000
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::b172:affa:cf1d:384e]) by DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::b172:affa:cf1d:384e%18]) with mapi id 15.20.0077.011; Mon, 25 Sep 2017 17:21:39 +0000
From: Rodney Cummings 
To: Tal Mizrahi 
CC: "tictoc@ietf.org" , "ntp@ietf.org" 
Thread-Topic: [TICTOC] Guidelines for Defining Packet Timestamps
Thread-Index: AQHTNTpMvNLEW+VMsEedh0vQp3P1WaLFseJQgAAHFICAACAXMA==
Date: Mon, 25 Sep 2017 17:21:39 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.164.62.43]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0401MB1391; 6:jD2xYNZ+4oh22kE1MpNN/C45R8iQemZltBC7CwFZ932WWB1tg8YGck2eznPRqSx6m2iU09B661HLubvQ1DJRlG+ivtuJRJR6gCjb2XPfDfpjj0mb6GSD8VMnWDPCFhtXrtPgCvXU5MB/0Kj5dtBMU7gXuCc5pl6c66J65ORgfPCgEVZG2K2juTyB6flWGb/4oNjENGYBuOx3PPe6ILH4DKusNwxMerq37dMaE/rf2CmzgnSBvfNTWWXE7L547+A6yLgh2nN3kGn6NQC+160X/xWWkxGEKh5RHRY+SbCYmnZsEQoBxBfvh6g+gqMmL0tm6B2X2p3VF91pCl+1HJDtJA==; 5:wj64JWcgjn2Pq9pKZLHJqxM/Uv8DEBbTEeyLEDmH0mYYLIzEFW7S4ucvXb6GQ8COgU1Z9nCj0nip+CnrFZmTGEmatYm1mC19DaS5v4rVaEMfLXeA1HVkoEYxtgxhmmT6q8+PbxUNMHUiouv9GCYSag==; 24:sTxeiSa8peWYZtvDOvxFAaOH75Oy5Cgt9vFaD+mPhJIL6NQv24aA/AEQwU6k9qM7u9MmBAveWqg3h5ZYyrghdQMDlsU189VgPgEzZx2uUtQ=; 7:AgOikzq4YpC9tz8ncKDYqhUf83oWj2iWg1UgtHuPpz/KEGwvbThGcHIOBeZYIzNxfvHQkVJF3mulrS70mEKUVqUi85cqO07w4D8Kn9L/JetChPIx0vzpZFqJW+c5oOsBFDvhhwGUsqAzFbAZjoSV9VdBK1DJky5WM+D6rc8AUzqtjLjkM+fPl+7aepVgBYNS1TJ8RRAxIzuF2ZVDMed2B+XnUwlgjI0n84sf9RzC6U4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 8fd000be-a732-434c-06ae-08d50439e23b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR0401MB1391; 
x-ms-traffictypediagnostic: DM2PR0401MB1391:
x-exchange-antispam-report-test: UriScan:(10436049006162)(145744241990776);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0401MB1391; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0401MB1391; 
x-forefront-prvs: 04410E544A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(24454002)(51914003)(377454003)(199003)(189002)(8676002)(74316002)(6506006)(33656002)(305945005)(3280700002)(2900100001)(3660700001)(6246003)(101416001)(76176999)(54356999)(189998001)(39060400002)(4326008)(478600001)(66066001)(2906002)(25786009)(6436002)(106356001)(966005)(53546010)(5250100002)(8936002)(81166006)(81156014)(105586002)(68736007)(14454004)(97736004)(7736002)(9686003)(5660300001)(50986999)(316002)(6116002)(6916009)(229853002)(2950100002)(3846002)(54906003)(53936002)(6306002)(7696004)(86362001)(99286003)(575784001)(102836003)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0401MB1391; H:DM2PR0401MB1389.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ni.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 17:21:39.6709 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0401MB1391
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-25_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709250263
Archived-At: 
X-Mailman-Approved-At: Mon, 25 Sep 2017 10:32:03 -0700
Subject: Re: [Ntp] [TICTOC] Guidelines for Defining Packet Timestamps
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, 25 Sep 2017 17:21:47 -0000

VGhhbmtzIFRhbC4uLiBnb29kIHF1ZXN0aW9uLg0KDQpPbmUgcHJvdG9jb2wgSSBoYWQgaW4gbWlu
ZCBpcyBpbiB0aGUgaW5kdXN0cmlhbCBzcGFjZSwgaW4gZWFybHkgZHJhZnQgZm9ybSwgYW5kIG5v
dCBpbiBJRVRGIChvciBJRUVFKS4gTmV2ZXJ0aGVsZXNzLCBJIHRvb2sgYSBsb29rLCBhbmQgaXQg
dHVybnMgb3V0IHRoYXQgaXQgdXNlcyB0aGUgbG93ZXIgNjQtYml0cyAoaS5lLiBQVFAgdHJ1bmNh
dGVkIHRpbWVzdGFtcCkuIFRoZSByYXRpb25hbGUgaXMgdGhhdCB0aGV5IHdhbnQgdG8gbGV2ZXJh
Z2UgUFRQIGhhcmR3YXJlLCBhbmQgdGhleSBkaWRuJ3Qgc2VlIHRoZSB1cHBlciAxNiBiaXRzIGFz
IGVzc2VudGlhbC4NCg0KVGhpbmtpbmcgYWJvdXQgaXQgbW9yZS4uLiBJIHRlbmQgdG8gdGhpbmsg
dGhhdCB0aGUgUFRQIHRydW5jYXRlZCB0aW1lc3RhbXAgd2lsbCBiZSBzdWZmaWNpZW50Lg0KDQpJ
IHdpdGhkcmF3IG15IGNvbW1lbnQgIzEgYmVsb3cuIExldCdzIGp1c3Qga2VlcCB3aXRoIDY0LWJp
dHMgYW5kIHNlZSB3aGVyZSB0aGF0IGdvZXMuDQoNClJvZG5leQ0KDQpGcm9tOiBUYWwgTWl6cmFo
aSBbbWFpbHRvOnRhbC5taXpyYWhpLnBoZEBnbWFpbC5jb21dIA0KU2VudDogTW9uZGF5LCBTZXB0
ZW1iZXIgMjUsIDIwMTcgMTA6MjAgQU0NClRvOiBSb2RuZXkgQ3VtbWluZ3MgPHJvZG5leS5jdW1t
aW5nc0BuaS5jb20+DQpDYzogdGljdG9jQGlldGYub3JnOyBudHBAaWV0Zi5vcmcNClN1YmplY3Q6
IFJlOiBbVElDVE9DXSBHdWlkZWxpbmVzIGZvciBEZWZpbmluZyBQYWNrZXQgVGltZXN0YW1wcw0K
DQpIaSBSb2RuZXksDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLsKgDQpXZSB3aWxsIGNlcnRh
aW5seSB0YWtlIHRoZXNlIG5vdGVzIGludG8gY29uc2lkZXJhdGlvbiBpbiB0aGUgbmV4dCB2ZXJz
aW9uLg0KDQpDYW4geW91IHBsZWFzZSBlbGFib3JhdGUgd2hpY2ggcHJvdG9jb2xzIHVzZSB0aGUg
ODAtYml0IHRpbWVzdGFtcCBmb3JtYXQgKG90aGVyIHRoYW4gUFRQLCBvYnZpb3VzbHkpPw0KDQpU
aGFua3MsDQpUYWwuDQoNCg0KT24gTW9uLCBTZXAgMjUsIDIwMTcgYXQgNjowMSBQTSwgUm9kbmV5
IEN1bW1pbmdzIDxtYWlsdG86cm9kbmV5LmN1bW1pbmdzQG5pLmNvbT4gd3JvdGU6DQpIaSBUYWws
DQoNClRoaXMgaXMgYW4gZXhjZWxsZW50IGRyYWZ0LiBJIGhhdmUgYSBjb3VwbGUgb2Ygc3VnZ2Vz
dGlvbnMuDQoNCjEuIEFkZCB0aGUgUFRQIDgwLWJpdCBUaW1lc3RhbXAsIHNpbmNlIHRoZXJlIGFy
ZSBwcm90b2NvbHMgdXNpbmcgdGhhdCBhcyB3ZWxsLCBzb21lIHdpdGggaGFyZHdhcmUgc3VwcG9y
dC4NCg0KMi4gSW4gc2VjdGlvbiA0LCBhZGQgaW5mb3JtYXRpdmUgdGV4dCB0byBleHBsYWluIG9u
ZSBvZiB0aGUgYmVuZWZpdHMgb2Ygc3BlY2lmeWluZyBhIHNtYWxsIHNldCBvZiBmaXhlZCBmb3Jt
YXQgc3BlY2lmaWNhdGlvbnM6IGhhcmR3YXJlIHN1cHBvcnQuIFRoZSBsb3dlciBkb3duIGluIHRo
ZSBpbnRlcmZhY2Ugc3RhY2sgdGhhdCB0aW1lc3RhbXBpbmcgb2NjdXJzLCB0aGUgbW9yZSBhY2N1
cmF0ZSBhbmQgcHJlY2lzZSB0aGUgdGltZXN0YW1wLiBUaGlzIGlzIHdlbGwga25vd24gZm9yIFBU
UCwgZm9yIHdoaWNoIHRpbWVzdGFtcGluZyBpcyBvZnRlbiBkb25lIGF0IHRoZSBNQUMgb3IgUEhZ
IGxldmVsLiBIYXJkd2FyZSBzdXBwb3J0IGlzIHBvdGVudGlhbGx5IGEgcmVhc29uIHRvIGF2b2lk
IHRoZSBjb250cm9sIGZpZWxkIG1lbnRpb25lZCBpbiBzZWN0aW9uIDcsIGJlY2F1c2UgaGFyZHdh
cmUgdHlwaWNhbGx5IGNhbm5vdCBzdXBwb3J0ICJhbnkiIGZvcm1hdC4uLiBpZGVhbGx5IHRoaXMg
UkZDIHdpbGwgbmFycm93IGl0IGRvd24gdG8gMi0zIGF0IG1vc3QuDQoNClJvZG5leQ0KDQpGcm9t
OiBUSUNUT0MgW21haWx0bzptYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBUYWwgTWl6cmFoaQ0KU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTcgODozOCBB
TQ0KVG86IG1haWx0bzp0aWN0b2NAaWV0Zi5vcmc7IG1haWx0bzpudHBAaWV0Zi5vcmcNClN1Ympl
Y3Q6IFtUSUNUT0NdIEd1aWRlbGluZXMgZm9yIERlZmluaW5nIFBhY2tldCBUaW1lc3RhbXBzDQoN
CkhpLMKgDQoNCldlIGhhdmUgcmV2aXNlZCB0aGUgZHJhZnQgYmFzZWQgb24gdGhlIGNvbW1lbnRz
IHJlY2VpdmVkIGluIElFVEYgOTksIGFuZCBiYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbSBZYWFr
b3YgKHRoYW5rcyBZYWFrb3YpLg0KDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v
djIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRG1penJh
aGktMkRpbnRhcmVhLTJEcGFja2V0LTJEdGltZXN0YW1wc18mZD1Ed01GYVEmYz1JXzBZd29LeTd6
NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1NqaXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjRE
UGp0M2xKdXVwc3dXWWRuYm9LYlo4ayZtPXlVWnNqNkwwaWI5SjR3dTNrUE5hMU9RSks0TUpQQmwy
dk1jYTZScHZ4X1Emcz14ZEZqM3hUUC05RVpxbWFfODRUNmVXUTBwMFZsd01yZFhpbDZGRlUzRlcw
JmU9DQoNClRoZSBtYWluIGNoYW5nZXMgY29tcGFyZWQgdG8gdGhlIHByZXZpb3VzIHZlcnNpb24g
b2YgdGhlIGRyYWZ0Og0KLSBXZSBoYXZlIGV4dGVuZGVkIHRoZSBkaXNjdXNzaW9uIGFib3V0IHRo
ZSBmYWN0b3JzIHRoYXQgbWF5IGFmZmVjdCB0aGUgY2hvaWNlIG9mIHRoZSB0aW1lc3RhbXAgZm9y
bWF0Lg0KLSBBIG5ldyBzZWN0aW9uIGhhcyBiZWVuIGFkZGVkLCBjYWxsZWQgIlRpbWVzdGFtcCBV
c2UgQ2FzZXMiLg0KLSBUaGUgc3ljaHJvbml6YXRpb24gYXNwZWN0cyBoYXZlIGJlZW4gc2VwYXJh
dGVkIGZyb20gdGhlIHRpbWVzdGFtcCBmb3JtYXQsIGFsbG93aW5nIHRoZSB0aW1lc3RhbXAgZm9y
bWF0IHRvIGJlIGluZGVwZW5kZW50IG9mIGhvdyB0aW1lIGlzIHN5bmNocm9uaXplZC4NCg0KQW55
IGZ1cnRoZXIgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkNoZWVycywNClRhbCwgSm9hY2hpbSwg
YW5kIEFsLg0KDQo=


From nobody Mon Sep 25 14: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 7282E132055; Mon, 25 Sep 2017 14:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 o6i-USFVsCO9; Mon, 25 Sep 2017 14:00:47 -0700 (PDT)
Received: from mail.nt.tuwien.ac.at (mail.nt.tuwien.ac.at [128.131.67.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC83126C0F; Mon, 25 Sep 2017 14:00:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.nt.tuwien.ac.at (Postfix) with ESMTP id B834926F1EC8; Mon, 25 Sep 2017 23:00:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at mydomain = nt.tuwien.ac.at
Received: from mail.nt.tuwien.ac.at ([127.0.0.1]) by localhost (mail.nt.tuwien.ac.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2v1iNoyl-qE; Mon, 25 Sep 2017 23:00:42 +0200 (CEST)
Received: from [10.0.0.82] (194-166-96-218.adsl.highway.telekom.at [194.166.96.218]) by mail.nt.tuwien.ac.at (Postfix) with ESMTPSA id 68DFF26F1EBA; Mon, 25 Sep 2017 23:00:42 +0200 (CEST)
To: Warner Losh , Tal Mizrahi 
Cc: ntp@ietf.org, tictoc@ietf.org
References:    
From: Joachim Fabini 
Message-ID: <463e1b90-0e63-2903-fae8-e298e94b7e77@tuwien.ac.at>
Date: Mon, 25 Sep 2017 23:00:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Ntp] Guidelines for Defining Packet Timestamps
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, 25 Sep 2017 21:00:49 -0000

Hi Warner,

thanks for your input, it triggered some additional ideas. As co-author
of the draft I'm adding some thoughts to this discussion - please find
the comments to your statements inserted inline.

On 25.09.2017 15:17, Warner Losh wrote:
> 
> 
> On Mon, Sep 25, 2017 at 12:37 AM, Tal Mizrahi  > wrote:
>
>     >Section 4.1 says "Further considerations may be discussed in 
>     >this section, such as required accuracy, or leap second handling." 
>     >Yet none of the formats make any allowance for leap seconds.
> 
>     Right. As I pointed out below, we have separated the *formats* from
>     the *synchronization aspects*. The advantage of this approach is
>     that a given timestamp format does not necessarily define the time
>     standard (UTC / TAI), and specifically does not necessarily define
>     the leap second handling.
> 
> 
> That's not an advantage by any means. If you don't know how to interpret
> the data, it's useless. 

I agree that timestamp interpretation (semantics) must be made explicit.
But I argue that interpretation needs not be explicit part of _any_
timestamp field.
Adding (a) interpretation by extending _any_ timestamp protocol field is
 one option. But there are many other ways to convey semantics. Examples
include, but are not limited to b) preliminary (one-time) agreement
between communicating parties (semantics negotiated once at connection
establishment time and valid throughout the session) or even c)
well-defined semantics in a textual standard or protocol specification.

Variants (a)-(c) are all realistic use cases that have their pros and
cons. A generic timestamp draft must support all of these use cases (and
likely some more).

> And leap seconds are part of the data, as much
> as people want to ignore them. It's a flaw in the specification. You go
> to great lengths to say that the PPT is seconds since a time in TAI. How
> you count the seconds since the epoch is quite relevant. It's not just a
> counter, but a corrected counter in NTP's case. And a counter and a
> corrected counter are two very different things, since the math you can
> safely do on them, and the meta data you need for some operations with
> them differ. You can't escape that in defining the format because that's
> critical to its use. And a corrected counter has ambiguities around the
> leap second that are impossible to avoid without other metadata (NTP
> puts that metadata into another bit of the NTP packet so you know, for
> example). The details about the metadata likely can remain unspecified,
> but whether or not leap seconds are swizzled in should not.
> 

Becoming more technical: the greatest common factor that current
protocols share wrt timestamps is a set of timestamp (data) fields of a
specific size. This is what the timestamp draft already covers in
detail. Interpretation - i.e., semantics - is currently up to the
protocols that use these timestamp data fields. Some protocols define
control fields on this purpose, but these are proprietary.

This draft will eventually contribute exactly what is currently missing
(and only present as a placeholder): a standardized control field that
_can_ be used by protocols to extend timestamp data fields with
semantics. Protocols that are willing to use the control field (and
accept its overhead) can add semantics to their timestamps. In some
cases it may even be used separated from timestamp data - for instance
when negotiating a connection in the case (b) mentioned earlier.
Prerequisite is that these semantics persist over connection lifetime,
which may or may not be true and applicable.

In other cases it may be meaningful for protocols to augment any single
timestamp with semantics. A timestamp control field could, for instance,
convey information on (estimated) local time synchronization accuracy
(like IEEE C37.118/2011 does). Or on leap seconds. And there are many
more cases.

Btw, while writing these lines I realize that it may even be worth to
differentiate between static timestamp semantics (valid over an
association lifetime) and dynamical semantics (that are valid for the
instant in time when the timestamp was generated).
 
> 
>     That means that a specification that uses a recommended timestamp
>     format should define the synchronization aspects, including leap
>     second considerations if such exist. See the following text in the
>     draft:
> 
>        A specification that uses one of the recommended timestamp formats
>        should also include a section on Synchronization Aspects...   
>        ...such as required accuracy, or leap second handling.
> 
> 
>     With that said, your point is well taken. In the next draft we will
>     add some more text that clarifies this point, including an example
>     in Section 5.
> 
> 
> As someone who has fought with formats being under specified, I can tell
> right now that this will lead to trouble. You can't run away from the
> Synchronization Aspects, at least not all of them. Having dealt with
> this stuff for almost two decades in high precision time applications,
> and having tried to separate out the two concepts to make things
> "cleaner" I can attest from first hand experience that this is a mistake.

Imho no timestamp format can ever prevent protocol designers from
under-specifying their timestamps. But the timestamp draft will support
them by providing guidance and eventually improve the status quo.

Your practical expertise and the one of other experts in ntp is an
invaluable help in figuring out the semantics that timestamps really
need. Finding the right trade-off between features, flexibility,
representation (size) and simplicity will be a major challenge. Likewise
we must find solutions for conflicting requirements (for instance Rodney
raised the topic of hardware support and the use of a control field).

So there's plenty of work ahead but imo it's worth spending the effort.
The discussion shows that there is a need for this draft and that
ntp/tictoc is the right group to host it. This, again, supports the
request for adoption as WG item.

thanks again,
Joachim


From nobody Wed Sep 27 12:20:42 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 5BC591323F7 for ; Wed, 27 Sep 2017 12:20:41 -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] 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 1oQJhTrr6dey for ; Wed, 27 Sep 2017 12:20:40 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012AE134EFC for ; Wed, 27 Sep 2017 12:20:39 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D5BA58810A for ; Wed, 27 Sep 2017 12:20:39 -0700 (PDT)
Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9FFE83284005 for ; Wed, 27 Sep 2017 12:20:39 -0700 (PDT)
To: ntp@ietf.org
References: <150575413583.15695.17336571829984618139.idtracker@ietfa.amsl.com> <71289c4f-656e-d4c0-bc30-dcc1135db5d3@innovationslab.net>
From: Brian Haberman 
Message-ID: <31f3c112-d2df-4322-182a-5e9afed2e5f8@innovationslab.net>
Date: Wed, 27 Sep 2017 15:20:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <71289c4f-656e-d4c0-bc30-dcc1135db5d3@innovationslab.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sM5xSLjVShLflThMdU2bdaSSsWNHxdCXp"
Archived-At: 
Subject: Re: [Ntp] New Version Notification for draft-ietf-ntp-mode-6-cmds-03.txt
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, 27 Sep 2017 19:20:41 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--sM5xSLjVShLflThMdU2bdaSSsWNHxdCXp
Content-Type: multipart/mixed; boundary="KR3qcCR95KPPQX4qi9eB9ihpLWEwaKCcA";
 protected-headers="v1"
From: Brian Haberman 
To: ntp@ietf.org
Message-ID: <31f3c112-d2df-4322-182a-5e9afed2e5f8@innovationslab.net>
Subject: Re: [Ntp] New Version Notification for
 draft-ietf-ntp-mode-6-cmds-03.txt
References: <150575413583.15695.17336571829984618139.idtracker@ietfa.amsl.com>
 <71289c4f-656e-d4c0-bc30-dcc1135db5d3@innovationslab.net>
In-Reply-To: <71289c4f-656e-d4c0-bc30-dcc1135db5d3@innovationslab.net>

--KR3qcCR95KPPQX4qi9eB9ihpLWEwaKCcA
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

All,
     Harlan asked for the ability to see the XML source for the draft,
so I posted it on GitHub. The draft source is visible at:

https://github.com/bkhabs/ntp-mode-6

Regards,
Brian

On 9/18/17 1:05 PM, Brian Haberman wrote:
> All,
>      This version addresses some minor comments received from several
> folks. I will send out additional emails with the current outstanding
> issues that need to be addressed.
>=20
> Regards,
> Brian
>=20
>=20
> On 9/18/17 1:02 PM, internet-drafts@ietf.org wrote:
>>
>> A new version of I-D, draft-ietf-ntp-mode-6-cmds-03.txt
>> has been successfully submitted by Brian Haberman and posted to the
>> IETF repository.
>>
>> Name:		draft-ietf-ntp-mode-6-cmds
>> Revision:	03
>> Title:		Control Messages Protocol for Use with Network Time Protocol V=
ersion 4
>> Document date:	2017-09-18
>> Group:		ntp
>> Pages:		21
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-ntp-mo=
de-6-cmds-03.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6=
-cmds/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds=
-03
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ntp-m=
ode-6-cmds-03
>> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ntp-mod=
e-6-cmds-03
>>
>> Abstract:
>>    This document describes the structure of the control messages used
>>    with the Network Time Protocol.  These control messages can be used=

>>    to monitor and control the Network Time Protocol application runnin=
g
>>    on any IP network attached computer.  The information in this
>>    document was originally described in Appendix B of RFC 1305.  The
>>    goal of this document is to provide a historic description of the
>>    control messages.
>>
>>                                                                       =
           =20
>>
>>
>> Please note that it may take a couple of minutes from the time of subm=
ission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>=20
>=20
>=20
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>=20


--KR3qcCR95KPPQX4qi9eB9ihpLWEwaKCcA--

--sM5xSLjVShLflThMdU2bdaSSsWNHxdCXp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZy/oEAAoJEGjWPJxT0YthzZ0QAIFNR4vxHamXEEvIbwTzLX0s
XnspVLIhkyylRe16n+5AXYnYChFjirMVahEjRun8ducKSN2OLzqPnkeMKDo5E74X
t2X94KXUtJP+rBO37VHSg/JLkxEPp4Y/pZb45ty8Dy9Pcg7GOs48s51jBppvPpCU
urhZbVMzIYly4PoEHjikkv1k9NqpzflBD0UxMRCcRIsig6CDmVFx/mZgES3ZTzSE
74Wme13crkMRc6war0vqiiihazj+14nOYKvRoCRBFOPvG+YCrQmO+1zrZ49xZTLw
wxdc3rUqpb9s9akaKcA4lCAubgGsVwic4+CVKCDk9F/TLZLDeaFf/KFQMPJ8Pw9I
qCNA63WmwhekQpaOmuTdw97TGRfis4mEtBOL10crOUpPs+ureYa76k+2p2g8H8+Q
CqLNtXCX7fSxzoU9yziXtqnV1W4XBHZqUPxxtKIrQohfPKksyQ7UN5lZhl1HOXv4
c8gijMzcrcCfRNcelXx4VtskKduBpn8VHLQmukbpGDmWy9AlNVE0n6hr99k56R18
s8cEimH8Fx1kkdMTqxcJxrY5eXoyC7l7F7xKLlqIB8r9M7O+sAPQUxPiBHl4BwO0
z9lty+rc88OD/onlNrTkIJXYIZe75QpphSmOL/WvX4Ws+/45LBErRIfVsC9OfRrm
G8xe3bd2JPBR2sa4aPMP
=Y7kt
-----END PGP SIGNATURE-----

--sM5xSLjVShLflThMdU2bdaSSsWNHxdCXp--


From nobody Thu Sep 28 21:02:39 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 7F2A41344BF; Thu, 28 Sep 2017 21:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level: 
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=isoc.org
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 XGK-Mchkj_nw; Thu, 28 Sep 2017 21:02:20 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0065.outbound.protection.outlook.com [104.47.41.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4240D132331; Thu, 28 Sep 2017 21:02:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Sp+ria3pcaSYqiRWtOG1ar8VOgWz7NkTtV/+TvbhmSQ=; b=wWurAKlgLq7CnuRJkCDPkZrXp+I3pwZS+uavdoZAx6oLhoT3TEQc2WPYgEFEzcmRsk9bEWFk/5XSXOrMilNwTuRS5q2igz3n9L0T74BMNLAPUc4kmu2qvQPyMiht04BGYguzdrgmWdfI9QJO0cF0ijU/zDFEYE+8gc/seOGrYIE=
Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2455.namprd06.prod.outlook.com (10.169.186.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 29 Sep 2017 04:02:19 +0000
Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0077.016; Fri, 29 Sep 2017 04:02:18 +0000
From: Karen O'Donoghue 
To: "ntp@ietf.org" , "tictoc@ietf.org" 
Thread-Topic: Reminder (Was: Joint NTP and TICTOC WGs virtual interim (Friday,  29 September, 1530-1700 UTC))
Thread-Index: AQHTONe+fBpNAxJJfEmZogK4h0oUEQ==
Date: Fri, 29 Sep 2017 04:02:18 +0000
Message-ID: <0AD26D09-AACA-4BC0-8915-A5E4A830730B@isoc.org>
References: <6C05DFDC-9F99-41E2-A6C0-5FD2078F7799@isoc.org>
In-Reply-To: <6C05DFDC-9F99-41E2-A6C0-5FD2078F7799@isoc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; 
x-originating-ip: [173.44.72.144]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR06MB2455; 6:t/YaCrxy0AJTWmgLj68TcnxDuploxEfIP54SiR0ZbjHDT8bQJcsZdrYdYI5ECMjlte1Ntry3635LOkhX3tUe8uF2hD875OSupnR0xbuqeVtQb9pYlNHLbKnxBykDMkrEclUbpQmNzBqrn4HVRERqeg/Y41ml3ew4ywIOTyOQCAMJ/TtBPPr/Tx/ru9U5DCmxfqtvhA+qENhnKZ1Lpy/Xp6IqRTCWoG3KiWbA3qxOAAGD6PH+ZQQQRwb2t/OUTlz5N2w2/px2aeQ8qo1MybbgfSPdYfmpwHTJd6ONEXB64H9ISNezzYCbJpgir4nWHmasF1uX7nodX593iMC5T7hPtg==; 5:uWFNKhAtbVZV2HUa1THAgmCvMgj6lHrt/fkU9t92cyJ5CRH/4A5nC2dX1G1kfLFcAZca6Zeote8F1R0B7KBaGHl/ISChQ5Q9CM/RxOPrfSdru0UguH1+4zkdYt/g+m0nt6N2zTJ7sZdZTf7i+nIleQ==; 24:qgZQgCFfJPKwxgPIzYOAB1dyi4X2jcUvkmLuGe4lcGHWtmODwZGxEGNqUNIYCkJZ412nZDQ3Nx0qQgStSd7vAGlzG7hmLlRa/ffvbtP5h84=; 7:PWCJReCcvd9P83X9U0OgGl7s7tb16Qa0BLLXV+wDsD58tG9Um8a0x3Ni3l7ILKTZ6agdRKh8qD0FG9QhVkzLRC5aolUAweoVyy2I5k01hB0G7q3oeyupEb96rFXRzPGB/CthE7uGmNskxWFJJXmkTXZ23WVBCNUXASOM6F2PLXCdnbhV8DPQlORLJaSiyXLXhL9aj9hORkkFNLQWal3/Q3WxczEwWIWET8rdVBC1zg0=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 6b9dde95-b178-4b4c-7485-08d506eee104
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR06MB2455; 
x-ms-traffictypediagnostic: CY4PR06MB2455:
x-exchange-antispam-report-test: UriScan:(120809045254105)(257447070540367);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2455; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2455; 
x-forefront-prvs: 0445A82F82
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39830400002)(189002)(497574002)(12213003)(24454002)(377454003)(199003)(3846002)(14454004)(54356999)(66066001)(82746002)(36756003)(68736007)(3660700001)(86362001)(2906002)(450100002)(3280700002)(966005)(5660300001)(7736002)(6306002)(77096006)(97736004)(83716003)(6486002)(189998001)(53936002)(50986999)(110136005)(25786009)(6512007)(54896002)(316002)(6436002)(6506006)(105586002)(33656002)(2950100002)(478600001)(101416001)(53546010)(99286003)(2900100001)(236005)(606006)(76176999)(102836003)(8936002)(6116002)(81156014)(2501003)(81166006)(106356001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2455; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_0AD26D09AACA4BC08915A5E4A830730Bisocorg_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2017 04:02:18.7680 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2455
Archived-At: 
Subject: [Ntp] Reminder (Was: Joint NTP and TICTOC WGs virtual interim (Friday, 29 September, 1530-1700 UTC))
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: Fri, 29 Sep 2017 04:02:22 -0000

--_000_0AD26D09AACA4BC08915A5E4A830730Bisocorg_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIG1lZXRpbmcgaXMgaW4gc2xpZ2h0bHkgbGVzcyB0aGFuIDEyIGhvdXJz4oCmDQoNCkthcmVu
DQoNCk9uIFNlcCAxMywgMjAxNywgYXQgNDowOSBQTSwgS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9n
aHVlQGlzb2Mub3JnPG1haWx0bzpvZG9ub2dodWVAaXNvYy5vcmc+PiB3cm90ZToNCg0KRm9sa3Ms
DQoNClRoZXJlIHdpbGwgYmUgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBvZiB0aGUgSUVURiBO
VFAvVElDVE9DIHdvcmtpbmcgZ3JvdXBzIG9uIEZyaWRheSAyOSBTZXB0ZW1iZXIgMjAxNyAoMTUz
MCAtIDE3MDAgVVRDKS4gVGhlIGRyYWZ0IGFnZW5kYSBhbmQgem9vbSBjb29yZGluYXRlcyBhcmUg
cHJvdmlkZWQgYmVsb3cuIFBsZWFzZSBub3RlIHRoYXQgcHJpb3JpdHkgd2lsbCBiZSBnaXZlbiB0
byBkaXNjdXNzaW9uIG9mIFdHTEMgY29tbWVudHMgZHVyaW5nIHRoaXMgbWVldGluZy4NCg0KUmVn
YXJkcywNCkthcmVuDQoNCg0KRHJhZnQgQWdlbmRhOg0KPT09PT09PT09PT0NCg0KMS4gV0dMQyBj
b21tZW50IHJlc29sdXRpb24gYW5kIHdheSBmb3J3YXJkIGZvciBNQUMgdXBkYXRlIGZvciBOVFAN
Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLW1hYy8NCg0K
Mi4gV0dMQyBjb21tZW50IHJlc29sdXRpb24gYW5kIHdheSBmb3J3YXJkIGZvciBOVFMgZm9yIE5U
UA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAtdXNpbmct
bnRzLWZvci1udHAvDQoNCjMuIE5UUCBFeHRlbnNpb24gZmllbGRzDQpodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdGVubi1udHAtZXh0ZW5zaW9uLWZpZWxkcy8NCg0KNC4g
TlRQIENvbnRyb2wgbWVzc2FnZXMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWlldGYtbnRwLW1vZGUtNi1jbWRzLw0KDQo1LiBOVFAgRGF0YSBtaW5pbWl6YXRpb24NCmh0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLWRhdGEtbWluaW1p
emF0aW9uLw0KDQo2LiBXR0xDIGZvciBZQU5HIERhdGEgTW9kZWwgZm9yIElFRUUgMTU4OHYyDQpo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIt
eWFuZy8NCg0KNy4gSUVFRSAxNTg4IEVudGVycHJpc2UgUHJvZmlsZQ0KaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10aWN0b2MtcHRwLWVudGVycHJpc2UtcHJvZmls
ZS8NCg0KOC4gTm90IG9uIHRoZSBhZ2VuZGEgdG9kYXkgYnV0IG5vdCBmb3Jnb3R0ZW4NCmh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLWJjcC8NCmh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLXlhbmctZGF0YS1tb2RlbC8N
Cg0KOS4gQU9CDQoNCioqKioqKioqKioqIENhbGwgaW4gZGV0YWlscy4gKioqKioqKioqKioNCg0K
VG9waWM6IElFVEYgTlRQL1RJQ1RPQyB2aXJ0dWFsIGludGVyaW0gbWVldGluZw0KVGltZTogU2Vw
IDI5LCAyMDE3IDExOjMwIEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZSAoVVMgYW5kIENhbmFkYSkN
Cg0KSm9pbiBmcm9tIFBDLCBNYWMsIExpbnV4LCBpT1Mgb3IgQW5kcm9pZDogaHR0cHM6Ly9pc29j
Lnpvb20udXMvai84MDE0NDM5OTkNCg0KT3IgaVBob25lIG9uZS10YXAgOg0KICAgIFVTOiArMTY0
NjU1ODg2NTYsLDgwMTQ0Mzk5OSMgIG9yICsxNjY5OTAwNjgzMywsODAxNDQzOTk5Iw0KT3IgVGVs
ZXBob25l77yaDQogICAgRGlhbChmb3IgaGlnaGVyIHF1YWxpdHksIGRpYWwgYSBudW1iZXIgYmFz
ZWQgb24geW91ciBjdXJyZW50IGxvY2F0aW9uKe+8mg0KICAgICAgICBVUzogKzEgNjQ2IDU1OCA4
NjU2ICBvciArMSA2NjkgOTAwIDY4MzMNCiAgICBNZWV0aW5nIElEOiA4MDEgNDQzIDk5OQ0KICAg
IEludGVybmF0aW9uYWwgbnVtYmVycyBhdmFpbGFibGU6IGh0dHBzOi8vaXNvYy56b29tLnVzL3pv
b21jb25mZXJlbmNlP209MlZmQlktSVJzbmVQNDU5aGpWMjF2N01vMld5VzJnckoNCg0KT3IgYW4g
SC4zMjMvU0lQIHJvb20gc3lzdGVtOg0KICAgIEguMzIzOg0KICAgICAgICAxNjIuMjU1LjM3LjEx
IChVUyBXZXN0KQ0KICAgICAgICAxNjIuMjU1LjM2LjExIChVUyBFYXN0KQ0KICAgICAgICAyMjEu
MTIyLjg4LjE5NSAoQ2hpbmEpDQogICAgICAgIDExNS4xMTQuMTMxLjcgKEluZGlhKQ0KICAgICAg
ICAyMTMuMTkuMTQ0LjExMCAoRU1FQSkNCiAgICAgICAgMjAyLjE3Ny4yMDcuMTU4IChBdXN0cmFs
aWEpDQogICAgICAgIDIwOS45LjIxMS4xMTAgKEhvbmcgS29uZykNCiAgICAgICAgNjQuMjExLjE0
NC4xNjAgKEJyYXppbCkNCiAgICBNZWV0aW5nIElEOiA4MDEgNDQzIDk5OQ0KDQogICAgU0lQOiA4
MDE0NDM5OTlAem9vbWNyYy5jb208bWFpbHRvOjgwMTQ0Mzk5OUB6b29tY3JjLmNvbT4NCg0KDQo=

--_000_0AD26D09AACA4BC08915A5E4A830730Bisocorg_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhlIG1lZXRpbmcgaXMgaW4gc2xp
Z2h0bHkgbGVzcyB0aGFuIDEyIGhvdXJz4oCmDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5LYXJlbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs
YXNzPSIiPk9uIFNlcCAxMywgMjAxNywgYXQgNDowOSBQTSwgS2FyZW4gTydEb25vZ2h1ZSAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZyIgY2xhc3M9IiI+b2Rvbm9naHVlQGlz
b2Mub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl
LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst
d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy
LXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkZvbGtzLDwvZGl2Pg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSB3aWxsIGJlIGEgdmlydHVhbCBpbnRlcmltIG1l
ZXRpbmcgb2YgdGhlIElFVEYgTlRQL1RJQ1RPQyB3b3JraW5nIGdyb3VwcyBvbiBGcmlkYXkgMjkg
U2VwdGVtYmVyIDIwMTcgKDE1MzAgLSAxNzAwIFVUQykuIFRoZSBkcmFmdCBhZ2VuZGEgYW5kIHpv
b20gY29vcmRpbmF0ZXMgYXJlIHByb3ZpZGVkIGJlbG93LiBQbGVhc2Ugbm90ZSB0aGF0IHByaW9y
aXR5IHdpbGwgYmUgZ2l2ZW4gdG8gZGlzY3Vzc2lvbiBvZiBXR0xDDQogY29tbWVudHMgZHVyaW5n
IHRoaXMgbWVldGluZy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkthcmVu
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxi
IGNsYXNzPSIiPkRyYWZ0IEFnZW5kYTombmJzcDs8L2I+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPj09
PT09PT09PT09PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj4xLiBXR0xDIGNvbW1lbnQgcmVzb2x1dGlvbiBhbmQgd2F5IGZvcndhcmQgZm9y
IE1BQyB1cGRhdGUgZm9yIE5UUCZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC1tYWMvIiBjbGFz
cz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC1tYWMv
PC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+Mi4gV0dMQyBjb21tZW50IHJlc29sdXRpb24gYW5kIHdheSBmb3J3YXJkIGZvciBOVFMg
Zm9yIE5UUDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC11c2luZy1udHMtZm9yLW50cC8iIGNsYXNzPSIi
Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLXVzaW5nLW50
cy1mb3ItbnRwLzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPjMuIE5UUCBFeHRlbnNpb24gZmllbGRzPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN0ZW5u
LW50cC1leHRlbnNpb24tZmllbGRzLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm
Lm9yZy9kb2MvZHJhZnQtc3Rlbm4tbnRwLWV4dGVuc2lvbi1maWVsZHMvPC9hPjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+NC4gTlRQIENv
bnRyb2wgbWVzc2FnZXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAtbW9kZS02LWNtZHMvIiBjbGFzcz0i
Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC1tb2RlLTYt
Y21kcy88L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj41LiBOVFAgRGF0YSBtaW5pbWl6YXRpb248L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAt
ZGF0YS1taW5pbWl6YXRpb24vIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1pZXRmLW50cC1kYXRhLW1pbmltaXphdGlvbi88L2E+PC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj42LiBXR0xDIGZvciBZ
QU5HIERhdGEgTW9kZWwgZm9yIElFRUUgMTU4OHYyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhy
ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGljdG9jLTE1
ODh2Mi15YW5nLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcvPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ny4gSUVFRSAxNTg4IEVudGVycHJpc2Ug
UHJvZmlsZSZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRpY3RvYy1wdHAtZW50ZXJwcmlzZS1wcm9m
aWxlLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0
Zi10aWN0b2MtcHRwLWVudGVycHJpc2UtcHJvZmlsZS88L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj44LiBOb3Qgb24gdGhlIGFnZW5k
YSB0b2RheSBidXQgbm90IGZvcmdvdHRlbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC1iY3AvIiBjbGFz
cz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC1iY3Av
PC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC15YW5nLWRhdGEtbW9kZWwvIiBjbGFzcz0iIj5odHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC15YW5nLWRhdGEtbW9k
ZWwvPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+OS4gQU9CJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0i
Ij4qKioqKioqKioqKiBDYWxsIGluIGRldGFpbHMuICoqKioqKioqKioqPC9iPjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VG9waWM6IElF
VEYgTlRQL1RJQ1RPQyB2aXJ0dWFsIGludGVyaW0gbWVldGluZzwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij5UaW1lOiBTZXAgMjksIDIwMTcgMTE6MzAgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lIChVUyBh
bmQgQ2FuYWRhKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+Sm9pbiBmcm9tIFBDLCBNYWMsIExpbnV4LCBpT1Mgb3IgQW5kcm9pZDogPGEg
aHJlZj0iaHR0cHM6Ly9pc29jLnpvb20udXMvai84MDE0NDM5OTkiIGNsYXNzPSIiPg0KaHR0cHM6
Ly9pc29jLnpvb20udXMvai84MDE0NDM5OTk8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj
bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5PciBpUGhvbmUgb25lLXRhcCA6PC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgVVM6ICYjNDM7MTY0NjU1ODg2NTYsLDgwMTQ0
Mzk5OSMgJm5ic3A7b3IgJiM0MzsxNjY5OTAwNjgzMywsODAxNDQzOTk5IyZuYnNwOzwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj5PciBUZWxlcGhvbmXvvJo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7
ICZuYnNwOyBEaWFsKGZvciBoaWdoZXIgcXVhbGl0eSwgZGlhbCBhIG51bWJlciBiYXNlZCBvbiB5
b3VyIGN1cnJlbnQgbG9jYXRpb24p77yaPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyBVUzogJiM0MzsxIDY0NiA1NTggODY1NiAmbmJzcDtvciAmIzQzOzEg
NjY5IDkwMCA2ODMzJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgTWVl
dGluZyBJRDogODAxIDQ0MyA5OTk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyBJ
bnRlcm5hdGlvbmFsIG51bWJlcnMgYXZhaWxhYmxlOiA8YSBocmVmPSJodHRwczovL2lzb2Muem9v
bS51cy96b29tY29uZmVyZW5jZT9tPTJWZkJZLUlSc25lUDQ1OWhqVjIxdjdNbzJXeVcyZ3JKIiBj
bGFzcz0iIj4NCmh0dHBzOi8vaXNvYy56b29tLnVzL3pvb21jb25mZXJlbmNlP209MlZmQlktSVJz
bmVQNDU5aGpWMjF2N01vMld5VzJncko8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5PciBhbiBILjMyMy9TSVAgcm9vbSBzeXN0ZW06
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgSC4zMjM6Jm5ic3A7PC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxNjIuMjU1LjM3LjExIChV
UyBXZXN0KTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
MTYyLjI1NS4zNi4xMSAoVVMgRWFzdCk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IDIyMS4xMjIuODguMTk1IChDaGluYSk8L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDExNS4xMTQuMTMxLjcgKEluZGlhKTwvZGl2
Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjEzLjE5LjE0NC4x
MTAgKEVNRUEpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAyMDIuMTc3LjIwNy4xNTggKEF1c3RyYWxpYSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwOS45LjIxMS4xMTAgKEhvbmcgS29uZyk8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDY0LjIxMS4xNDQuMTYwIChC
cmF6aWwpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgTWVldGluZyBJRDogODAx
IDQ0MyA5OTk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgU0lQOiA8YSBocmVmPSJtYWlsdG86ODAxNDQzOTk5QHpv
b21jcmMuY29tIiBjbGFzcz0iIj44MDE0NDM5OTlAem9vbWNyYy5jb208L2E+PC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_0AD26D09AACA4BC08915A5E4A830730Bisocorg_--


From nobody Fri Sep 29 03:15:26 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 2EE95132D14 for ; Fri, 29 Sep 2017 03:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 s-TOZcm8k0-n for ; Fri, 29 Sep 2017 03:15:22 -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 D904A132320 for ; Fri, 29 Sep 2017 03:15:22 -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 60718B836; Fri, 29 Sep 2017 10:15:22 +0000 (UTC)
To: "ntp@ietf.org" 
From: Harlan Stenn 
Message-ID: <1cee53dd-9942-1e29-1595-df11bef5218e@nwtime.org>
Date: Fri, 29 Sep 2017 03:15:20 -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: 8bit
Archived-At: 
Subject: [Ntp] draft-stenn-ntp-extension-fields-02
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: Fri, 29 Sep 2017 10:15:24 -0000

Folks,

I've added a bunch of clarifying language to the document, based on the
phone call between Karen, Dieter, Tal, Danny, and me earlier this week.

There are still at least 3 things needed:

- Additional language in the Abstract to mention content that is
significant to the EF/MAC discussion that was only present in RFC5906.

- The two examples of parsing pseudocode.

I'm doing this work out of:

 https://github.com/hstenn/ietf-ntp-extension-field.git
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!