From nobody Wed Nov 1 02:41: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 3869C13F69D for ; Wed, 1 Nov 2017 02:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDOWDEDAfSCY for ; Wed, 1 Nov 2017 02:41:28 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 0DF931395F0 for ; Wed, 1 Nov 2017 02:41:28 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id m198so2600408oig.5 for ; Wed, 01 Nov 2017 02:41:28 -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=alf3VbUpeLfOoEeS8+kHA2DVpmiHL7lfEZ6W7UYQJZM=; b=JHuYG8KmP751wO9l9JNt2m/yS/k9uzjRqiAstHcSZehPkV89917zS9CWLtgVnDQpg5 IQ22fKR8+ZrjEb81LMf6qnHVUDJV/+o8lqF8ponc9SPrdNTZzGSncS0UZZLqeCRAA08V AZjJrYH8itR9am6P+ggOOD695KlchuqG231YK6KWE3iSTPRZJDHZ+4zjtu1MOMcBKhtv FGjCeEwqIySQsZCqRl0/cgm6iyyrRK+URHowq+mqahu3C7Z5B8OTVukB/r4X8G12Oswo f+kl5SqUxL+UMIcLmjInOBDtSk5z5IGJjcW9+aL5mnZA7FDcFteGcb2yYJ4+vJ8TpB8c hGyA== 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=alf3VbUpeLfOoEeS8+kHA2DVpmiHL7lfEZ6W7UYQJZM=; b=adQoh9QRv9a2SGK7zn91XxH722/P1vTXOvvlePkApxN5PVMg1S7eJt8N3noIsYjq57 jYyolY5U11ok5J/ZkRgZmfAoO9xZbHhox/k1IFh48Ee1frlzxGG6l48ss+TOVkFoleqj fN18mo+d4k4ulub0OpDsz59gCWiRgHq+CFPGPorBChIZyUL1GW0yH0autT+XHU9YfTrz VGcWk8JB2YdumUL1Sgk1wxOnl0RJEhwo4YpJ97cbZo/HbdX7VcdFXXRqdS/z2j6cuqdb AgyYZ9m3Axb0zIj9OlcLJOmLpl4qFsd8hCo9Bc0fhUcaCwyP6G9wjnvfMLFP3S6tDQmc 7m+w== X-Gm-Message-State: AMCzsaX5Urc2mRjPMQX2KWGnwm03jAjRA9eDV4ObqeaYuGGSPjfTt2Qh roZOxgMh0rWZJsM9E24p5H6Ilo/ckgJIOPtnNXY= X-Google-Smtp-Source: ABhQp+SPR+bzJ+bD2EzK1mJXQlGYwKMXTVzCGBUsaxCEUtsw/dyErfAz5PA2tTSUHrf4t/zRRVhWxMr8+TdWUtaWVk8= X-Received: by 10.157.19.10 with SMTP id f10mr2567763ote.493.1509529287351; Wed, 01 Nov 2017 02:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.25.194 with HTTP; Wed, 1 Nov 2017 02:41:26 -0700 (PDT) In-Reply-To: References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> <20171031155717.GC7648@localhost> From: Tal Mizrahi Date: Wed, 1 Nov 2017 11:41:26 +0200 Message-ID: To: Miroslav Lichvar Cc: ntp@ietf.org, Aanchal Malhotra Content-Type: multipart/alternative; boundary="001a11409f6af36448055ce8ac78" Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 09:41:30 -0000 --001a11409f6af36448055ce8ac78 Content-Type: text/plain; charset="UTF-8" Small correction: Slow-to-fast cut-through is *not* possible. Fast-to-slow cut-through *is* possible. I had it reversed in my previous mail. :) Regards, Tal. On Wed, Nov 1, 2017 at 8:48 AM, Tal Mizrahi wrote: > Hi Miroslav, > > >> Moreover, we never know which nodes along the path use > store-and-forward, > >> and which nodes use cut-through. In cut-through forwarding the packet > >> transmission may start before the last bit is received, so it certainly > >> makes more sense to measure the first-bit-in-to-first-bit-out. > > > >That's a good point. With cut-through switching the correction would > >be negative and generally couldn't be determined in time to be put in > >the packet as the length is unknown. Are there any switches that can > >cut-through from a faster link to slower link? > > To the best of my knowledge cut-through from a fast link to a slow link is > not possible. Cut-through from a slow link to a fast link is certainly > possible, and of course between ports that have the same link speed. > In the two latter cases the transmission may start before the end of the > reception. > > Regards, > Tal. > > > > On Tue, Oct 31, 2017 at 5:57 PM, Miroslav Lichvar > wrote: > >> On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote: >> > >With NTP there is generally no HW support, so clients and servers >> > >should use trailer RX timestamps and preamble TX timestamps to avoid >> > >an asymmetric delay with different link speeds. The following document >> > >explains the issue nicely. >> > > >> > >https://www.eecis.udel.edu/~mills/stamp.html >> > > >> > >Do you think it will be difficult to implement? If the link speed and >> > >length of the packet is known, the timestamp can be transposed. >> > >> > The link speed is not necessarily known to the end points. >> >> I meant that the devices which are supposed to modify the correction >> field know the link speed and can transpose preamble timestamps if >> necessary. >> >> The end points don't need to know the link speed on the path. Just the >> speed of their own link if they need to transpose their timestamps. >> >> > Furthermore, the >> > link speed may change several times along the path. >> >> In such case we want the correction to still be symmetric, right? >> >> > Maybe I am missing something, but it appears that when measuring >> > last-bit-in-to-first-bit-out we are ignoring the packet reception time; >> it >> > seems to make sense to include the packet reception time in the >> residence >> > time. >> >> For PTP yes, but not for NTP. The reception time is included in the >> network delay as measured by the client, which will be symmetric as >> long as no device on the path includes in the correction the >> transmission time or reception time. >> >> > Moreover, we never know which nodes along the path use >> store-and-forward, >> > and which nodes use cut-through. In cut-through forwarding the packet >> > transmission may start before the last bit is received, so it certainly >> > makes more sense to measure the first-bit-in-to-first-bit-out. >> >> That's a good point. With cut-through switching the correction would >> be negative and generally couldn't be determined in time to be put in >> the packet as the length is unknown. Are there any switches that can >> cut-through from a faster link to slower link? >> >> Maybe it would make sense to allow corrections from preamble RX >> timestamps when the link speeds are equal. >> >> > >The reason for a separate transmit correction is to support the >> > >interleaved modes. The receive correction might not be necessary. If >> > >you have a better use for the 2 octets, I think it could be dropped >> > >and included in the origin correction instead. >> > >> > So it looks like two correction fields would suffice: one for the >> forward >> > direction, and one for the reverse direction. Right? >> >> I think it's three fields if we want both support the interleaved >> modes and allow the client to check the delay correction in both >> directions. Where would be the transmit correction included if there >> were only two fields? >> >> -- >> Miroslav Lichvar >> > > --001a11409f6af36448055ce8ac78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Small correction:
Slow-to-fast cut-through is *not* po= ssible.
Fast-to-slow cut-through *is* possible.

I had it reversed in my previous mail. :)

= Regards,
Tal.=C2=A0

On Wed, Nov 1, 2017 at 8:48 AM, Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
Hi Miroslav,

>> Moreover, we never know which nodes along the path use store= -and-forward,
>> and which nodes use cut-through. In cut-th= rough forwarding the packet
>> transmission may start befor= e the last bit is received, so it certainly
>> makes more s= ense to measure the first-bit-in-to-first-bit-out.
>
>That's a good point. With cut-through switching the correction wou= ld
>be negative and generally couldn't be determined in ti= me to be put in
>the packet as the length is unknown. Are ther= e any switches that can
>cut-through from a faster link to slo= wer link?

To the best of my knowledge= cut-through from a fast link to a slow link is not possible.=C2=A0Cut-thro= ugh from a slow link to a fast link is certainly possible, and of course be= tween ports that have the same link speed.
In the two latter case= s the transmission may start before the end of the reception.
Regards,
Tal.



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

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

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

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

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

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

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

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

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

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

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

--
Miroslav Lichvar


--001a11409f6af36448055ce8ac78-- From nobody Thu Nov 2 01:10: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 07DB413FA6F; Thu, 2 Nov 2017 01:10:29 -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 OZTAsRm4hG_G; Thu, 2 Nov 2017 01:10: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 9911013F8FB; Thu, 2 Nov 2017 01:10:25 -0700 (PDT) Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A94E795B8; Thu, 2 Nov 2017 09:10:23 +0100 (CET) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id B119B79590; Thu, 2 Nov 2017 09:10:22 +0100 (CET) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Thu, 02 Nov 2017 09:10:22 +0100 Message-Id: <59FAD2EC020000A100028B00@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Thu, 02 Nov 2017 09:10:20 +0100 From: "Ulrich Windl" To: Cc: "ntp@ietf.org" References: <150939291573.7748.7204061647170712817@ietfa.amsl.com> In-Reply-To: <150939291573.7748.7204061647170712817@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [Ntp] Antw: I-D Action: draft-ietf-ntp-mac-02.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: Thu, 02 Nov 2017 08:10:29 -0000 Hi! After a quick browse I realized that the draft does not specify how to = detect that AES-CMAC was used instead of an MD5 Digest. Both are 128 bits = long. Regards, Ulrich >>> schrieb am 30.10.2017 um 20:48 in Nachricht <150939291573.7748.7204061647170712817@ietfa.amsl.com>: > 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. >=20 > Title : Message Authentication Code for the Network = Time=20 > Protocol > Authors : Aanchal Malhotra > Sharon Goldberg > Filename : draft-ietf-ntp-mac-02.txt > Pages : 4 > Date : 2017-10-30 >=20 > Abstract: > RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets > should be authenticated by appending a 128-bit key to the NTP data, > and hashing the result with MD5 to obtain a 128-bit tag. This > document deprecates MD5-based authentication, which is considered to > be too weak, and recommends the use of AES-CMAC [RFC4493] as a > replacement. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/=20 >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ntp-mac-02=20 > https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac-02=20 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ntp-mac-02=20 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/=20 >=20 > _______________________________________________ > ntp mailing list > ntp@ietf.org=20 > https://www.ietf.org/mailman/listinfo/ntp=20 From nobody Thu Nov 2 01:44:53 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 85E7413FA84 for ; Thu, 2 Nov 2017 01:44:51 -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 VkhTztNeIka2 for ; Thu, 2 Nov 2017 01:44:49 -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 E9F3613FA6F for ; Thu, 2 Nov 2017 01:44:49 -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 31B54B882; Thu, 2 Nov 2017 08:44:49 +0000 (UTC) To: ntp@ietf.org References: <150939291573.7748.7204061647170712817@ietfa.amsl.com> <59FAD2EC020000A100028B00@gwsmtp1.uni-regensburg.de> From: Harlan Stenn Message-ID: <3a4088be-d44a-534d-14fa-88d96d5df45d@nwtime.org> Date: Thu, 2 Nov 2017 01:44:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <59FAD2EC020000A100028B00@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: I-D Action: draft-ietf-ntp-mac-02.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: Thu, 02 Nov 2017 08:44:51 -0000 Ulrich, The algorithm used is part of the symmetric key file. It's a feature that we don't say what algorithm is used in the packet. People can use whatever algorithm they want, including MD5. This document simply says that a conforming implementation MUST support AES-128-CMAC, and that associations should stop using DES, and start using AES-128-CMAC instead. Again, they can also use any other algorithms they want to. H On 11/2/17 1:10 AM, Ulrich Windl wrote: > Hi! > > After a quick browse I realized that the draft does not specify how to detect that AES-CMAC was used instead of an MD5 Digest. Both are 128 bits long. > > Regards, > Ulrich > >>>> schrieb am 30.10.2017 um 20:48 in Nachricht > <150939291573.7748.7204061647170712817@ietfa.amsl.com>: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Network Time Protocol WG of the IETF. >> >> Title : Message Authentication Code for the Network Time >> Protocol >> Authors : Aanchal Malhotra >> Sharon Goldberg >> Filename : draft-ietf-ntp-mac-02.txt >> Pages : 4 >> Date : 2017-10-30 >> >> Abstract: >> RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets >> should be authenticated by appending a 128-bit key to the NTP data, >> and hashing the result with MD5 to obtain a 128-bit tag. This >> document deprecates MD5-based authentication, which is considered to >> be too weak, and recommends the use of AES-CMAC [RFC4493] as a >> replacement. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-ntp-mac-02 >> https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-mac-02 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > -- Harlan Stenn http://networktimefoundation.org - be a member! From nobody Thu Nov 2 03:03:23 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E22C13F5AD; Thu, 2 Nov 2017 03:03:21 -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 kdchk0Eq_K-h; Thu, 2 Nov 2017 03:03:18 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 73DAF13F4FA; Thu, 2 Nov 2017 03:03:18 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id c77so8007496oig.0; Thu, 02 Nov 2017 03:03:18 -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=FlEXVd+acvNlG/1ksII8JAygU2jupSDeyfBbHtc8NNQ=; b=T0xvFVsGiqnnBjU2p8uDQ/hdBXeGHgVasAJCFJhU12SWASP4WOFg+6YOGR0YKSgKpC mp4Iq99o7V7YI98khEBDk3uQj9wM/Ph174mBBNOjwL48PcGlBFSXaxa52ESyMThUWk+S TBxYYfZu2sWiqGWj0H3w99tpXQra1PbefVHdJ1iuroTyI2o5LPqYxq3qLj15MeIoxC63 Nqf6LfCcLYm+jeZFbt+xchynfmYwMlNV3U198cOyNyDgDF2H7fK9IQfkh7dVqLzKMXqT ghtx9R96cw8vUvCISyp8E9tA+d5CjhPxaWLFH1rVwlrvUGLwBLx4i+UhGvbXq28baPsT 03cA== 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=FlEXVd+acvNlG/1ksII8JAygU2jupSDeyfBbHtc8NNQ=; b=hNyXoe6RynkjvWo+dD1QG83IJH5fo5sibjjoQ0so3P16OTwO7DrTazZB3wGfnanpc5 vWospTmQ3Wccx1JoBA9Yq9xjGTT1aSyney25I6c+1FdkoGkpAvN4N4dwYo4lxQgtIcN0 Z7LQ76rlHz5wveeAqpYH9Bc6L/790Dbg3WNGNzOsJ4phW4XYbDSLlyJBpfvYFMnvjURj ksGDzmkyZKknMBSbinOYQBbb162+3YQbaNLTt1odQs+nPYJHeO2WY5LlgW4DsREwnLC2 ERoRbze3HYJtRCmXv+4PIdY81dwa6K9eAuZlxcGl6U/Ony3cASA0BQt+lXFnHw66bT9t IOSQ== X-Gm-Message-State: AMCzsaV66R92ZMnFwqsglY/bQN9z4CiBjOTnrjZMOV/O+GiGdpiSrZ2C iDqryinQVUu8AMMF6Tus0PAxN/L7DI6E9hj+CD4= X-Google-Smtp-Source: ABhQp+S+umvZo7bKmvxCshtM3LWl7a8yKS4RJkNvOTForqGXbdeXKpUIAAFk6+syfoUUW3aW6jwdIw4CG0LEHYwyYtc= X-Received: by 10.202.64.136 with SMTP id n130mr1681145oia.154.1509616997558; Thu, 02 Nov 2017 03:03:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.25.194 with HTTP; Thu, 2 Nov 2017 03:03:17 -0700 (PDT) In-Reply-To: <150939291573.7748.7204061647170712817@ietfa.amsl.com> References: <150939291573.7748.7204061647170712817@ietfa.amsl.com> From: Tal Mizrahi Date: Thu, 2 Nov 2017 12:03:17 +0200 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, ntp@ietf.org Content-Type: multipart/alternative; boundary="001a113db492e2ee1c055cfd1857" Archived-At: Subject: Re: [Ntp] I-D Action: draft-ietf-ntp-mac-02.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: Thu, 02 Nov 2017 10:03:21 -0000 --001a113db492e2ee1c055cfd1857 Content-Type: text/plain; charset="UTF-8" Hi, A couple of comments: - The "Security Considerations" section is missing. - It would be great if there was some text that discusses interoperability with previous versions of NTP (that use the legacy MAC). Thanks, Tal. On Mon, Oct 30, 2017 at 9:48 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Time Protocol WG of the IETF. > > Title : Message Authentication Code for the Network Time > Protocol > Authors : Aanchal Malhotra > Sharon Goldberg > Filename : draft-ietf-ntp-mac-02.txt > Pages : 4 > Date : 2017-10-30 > > Abstract: > RFC 5905 [RFC5905] states that Network Time Protocol (NTP) packets > should be authenticated by appending a 128-bit key to the NTP data, > and hashing the result with MD5 to obtain a 128-bit tag. This > document deprecates MD5-based authentication, which is considered to > be too weak, and recommends the use of AES-CMAC [RFC4493] as a > replacement. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ntp-mac-02 > https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-mac-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > --001a113db492e2ee1c055cfd1857 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A couple of comments:
- The "Security Considerations" section is missing.
- It would be great if there was some text that discusses interope= rability with previous versions of NTP (that use the legacy MAC).

Thanks,
Tal.


On Mon, Oct 30, 2017 at 9:4= 8 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Network Time Protocol WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Authentication Code for the Network Time Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Aanc= hal Malhotra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sharon Goldberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ntp-mac-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-30

Abstract:
=C2=A0 =C2=A0RFC 5905 [RFC5905] states that Network Time Protocol (NTP) pac= kets
=C2=A0 =C2=A0should be authenticated by appending a 128-bit key to the NTP = data,
=C2=A0 =C2=A0and hashing the result with MD5 to obtain a 128-bit tag.=C2=A0= This
=C2=A0 =C2=A0document deprecates MD5-based authentication, which is conside= red to
=C2=A0 =C2=A0be too weak, and recommends the use of AES-CMAC [RFC4493] as a=
=C2=A0 =C2=A0replacement.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf= -ntp-mac/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-mac= -02
https://datatracker.ietf.org/doc/htm= l/draft-ietf-ntp-mac-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-ntp-mac-02


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

--001a113db492e2ee1c055cfd1857-- From nobody Fri Nov 3 11:00:07 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 DA89F13FF0F for ; Fri, 3 Nov 2017 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 PVHKkpJIkAOF for ; Fri, 3 Nov 2017 11:00:05 -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 B661D13FF0A for ; Fri, 3 Nov 2017 11:00:05 -0700 (PDT) Received: from [10.10.10.112] (pool-71-174-223-28.bstnma.east.verizon.net [71.174.223.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id E3874B966; Fri, 3 Nov 2017 18:00:04 +0000 (UTC) From: Danny Mayer To: ntp@ietf.org Cc: "David L. Mills" Message-ID: <22f6f122-8c56-032e-c022-306607eaa588@ntp.org> Date: Fri, 3 Nov 2017 14:00:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ntp] NTS for NTP draft 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, 03 Nov 2017 18:00:07 -0000 First I'd like to apologize for not review this draft before but the last year has been extraordinarily full for me and I haven't had time to pay attention. I read the draft just before the interim meeting and it's not ready for last call. I'm going to just deal with the major issues as I see them. 1. Fundamentally ALL NTP packets are client/server, even the control ones. However section 1.2 seems to think that symmetric peer and control mode are exchanging packets. That's actually a total misunderstanding of the protocol. Symmetric peer mode are only different in how the timestamps are analyzed and when they return a response packet. Symmetric peers never exchange packets in the way that the document seems to think. A peer will send a request and get a response. At a separate time the server that responded to the packet will send a request to the other peer and get a response. 2. Peer, Client/Server are all handled the same way in the protocol. They only differ in the way they respond and how the data is handled when analyzing the data in the packets. 3. Broadcast and Multicast are only different in that the server sends a UDP broadcast or multicast NTP packet and a client which has subscribed to the broadcast or multicast group picks it up. The client does not initiate these packets. 3. Control packets are initiated by a client and responded to by the server. These are the only packets that one might want to secure to prevent DDOS attacks or even encrypt. However unlike other packets they can be handle by a key exchange OOB and there is no requirement to look at the protocol timestamps. Only admins really needs these packets and they should be controlling both ends. 4. The three DTLS proposals as documented in section 1.2 are useful ideas as a discussion paper but doesn't mean that they should all be used. 5. DTLS-encapsulated NTPv4 is not practical as it assumes that you are in effect keeping a channel going. In fact NTP packet requests can vary between every 16 seconds to once a day so this is not a good idea. Even worse, the timestamps will be way off what they need to be and would result in a large jitter among other problems which will result in them being rejected as too unreliable by the selection algorithms. Control mode doesn't need it since it can be secured using other methods as only an admin of such a server might need to use control mode. Symmetric peer mode as I stated above is the same as client/server and needs to be handle in the same way. 6. NTP packets are already protected against replay attacks so DTLS does not provide any additional protection. 7. There is no benefit to encrypting Extension Fields. There's nothing secret about them. NTS should be about the whole packet and not about the individual fields. 8. The response packet can be smaller than the request packet. For that matter if the response is slightly larger then it does not qualify as an amplification in the security sense. I have actual use cases which would make the response smaller. 9. Section 1.1 seems to be nothing but a wish list of attributes about a packet but unless each one is spelled out in detail in the specification and why it's useful there's no point to it. 10. AEAD (section 5.1.5) is not clear at all. When is it supposed to be used, why it should be used, what are the benefits and what are the issues with using it? 11. New Cookie (Section 5.1.6) why it is needed and the benefits of it. Furthermore in the discussion of NTS cookies (section 7) is this sentence: "Clients MUST NOT examine the cookie under the assumption that it is constructed according to this section". Clients should be free to examine anything they want, including a cookie. What is preventing them from examining the cookie? 12. In Section 7 we see: "Servers should periodically generate a new pair (I,K)". Doesn't that mean that it needs to maintain state which we already agreed is not a good idea for a server? Or does that mean that the server only has one cookie for all clients? Further on it talks about accepting old ones which means keeping more state. This does not scale. 13. TLS 1.3 is almost ready to be published as an RFC so why not use that as a minimum started point? Danny From nobody Fri Nov 3 15:27:07 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 5874A5698D for ; Fri, 3 Nov 2017 15:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.932 X-Spam-Level: ** X-Spam-Status: No, score=2.932 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 qHOKTs274F0j for ; Fri, 3 Nov 2017 15:27:05 -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 AAB9713FEF8 for ; Fri, 3 Nov 2017 15:27:05 -0700 (PDT) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 44627406061; Fri, 3 Nov 2017 15:27:04 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: ntp@ietf.org cc: hmurray@megapathdsl.net From: Hal Murray In-Reply-To: Message from Danny Mayer of "Fri, 03 Nov 2017 14:00:03 EDT." <22f6f122-8c56-032e-c022-306607eaa588@ntp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Nov 2017 15:27:04 -0700 Message-Id: <20171103222704.44627406061@ip-64-139-1-69.sjc.megapath.net> Archived-At: Subject: Re: [Ntp] NTS for NTP draft 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, 03 Nov 2017 22:27:06 -0000 How much would it simplify things to drop everything but the mainline client/server modes? How much would that help security? -- These are my opinions. I hate spam. From nobody Sun Nov 5 10:48: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 7571413FCB5 for ; Sun, 5 Nov 2017 10:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 X1fyB8UvlIID for ; Sun, 5 Nov 2017 10:48:20 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.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 5D2AB13FCB9 for ; Sun, 5 Nov 2017 10:48:19 -0800 (PST) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vA5IlGYo027344-vA5IlGYq027344 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 5 Nov 2017 19:47:16 +0100 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id B60465A5F48; Sun, 5 Nov 2017 19:47:15 +0100 (CET) MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <20171103222704.44627406061@ip-64-139-1-69.sjc.megapath.net> References: <20171103222704.44627406061@ip-64-139-1-69.sjc.megapath.net> From: dieter.sibold@ptb.de To: Hal Murray Cc: ntp@ietf.org Message-ID: Date: Sun, 5 Nov 2017 19:47:14 +0100 Content-Type: multipart/alternative; boundary="=_alternative 006733BBC12581CF_=" Archived-At: Subject: Re: [Ntp] NTS for NTP draft 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, 05 Nov 2017 18:48:22 -0000 --=_alternative 006733BBC12581CF_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The version 10 of the draft (uploaded at 30th Oct) contains only the client= -server mode. Everything else is removed. -----"ntp" wrote: ----- >To: ntp@ietf.org >From: Hal Murray=20 >Sent by: "ntp"=20 >Date: 11/03/2017 23:27 >Cc: hmurray@megapathdsl.net >Subject: Re: [Ntp] NTS for NTP draft > >How much would it simplify things to drop everything but the mainline > >client/server modes? > >How much would that help security? > > >--=20 >These are my opinions. I hate spam. > > > >=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 006733BBC12581CF_= Content-Type: text/html; charset=UTF-8 Content-ID: <> Content-Transfer-Encoding: quoted-printable
The version 10 of the draft (uploaded at 30th Oct) contains onl= y the client-server mode. Everything else is removed.

-----"ntp" <= ntp-bounces@iet= f.org> wrote: -----

<= div style=3D"margin: 0px; direction: ltr; font-family: Verdana, Arial, Helv= etica, sans-serif;">>To: ntp@ietf.org
>From: Hal Murray
>Sent by: "ntp"
>Date: 11/03/2017 23:27
>Subject: Re: [Ntp] NTS for NTP = draft
>
>= How much would it simplify things to drop everything but the mainline
>
>client/serv= er modes?
>
= >How much would that help security?
>
>
>--
=
>These are my opinions. I hate spam.
>
>
>
>=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
>
 --=_alternative 006733BBC12581CF_=-- From nobody Mon Nov 6 04:30:23 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8535E13FB18 for ; Mon, 6 Nov 2017 04:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCM58FuxrS0R for ; Mon, 6 Nov 2017 04:30:16 -0800 (PST) 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 2507F13FB08 for ; Mon, 6 Nov 2017 04:30:16 -0800 (PST) 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 A956781DED; Mon, 6 Nov 2017 12:30:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A956781DED 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 BC4DC5D6A8; Mon, 6 Nov 2017 12:30:14 +0000 (UTC) Date: Mon, 6 Nov 2017 13:29:50 +0100 From: Miroslav Lichvar To: Danny Mayer Cc: ntp@ietf.org, "David L. Mills" Message-ID: <20171106122950.GA18380@localhost> References: <22f6f122-8c56-032e-c022-306607eaa588@ntp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22f6f122-8c56-032e-c022-306607eaa588@ntp.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 06 Nov 2017 12:30:15 +0000 (UTC) Archived-At: Subject: Re: [Ntp] NTS for NTP draft 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, 06 Nov 2017 12:30:22 -0000 On Fri, Nov 03, 2017 at 02:00:03PM -0400, Danny Mayer wrote: > 1. Fundamentally ALL NTP packets are client/server, even the control > ones. However section 1.2 seems to think that symmetric peer and control > mode are exchanging packets. That's actually a total misunderstanding of > the protocol. Symmetric peer mode are only different in how the > timestamps are analyzed and when they return a response packet. > Symmetric peers never exchange packets in the way that the document > seems to think. A peer will send a request and get a response. At a > separate time the server that responded to the packet will send a > request to the other peer and get a response. That doesn't sound right to me. How would the peers know which packet is a response and which is a request? There is no bit in the NTP header that would indicate that. The active/passive mode is related to how is the association created, it does not say if it's a request or response, except the case when a server does not mobilize an association with a host that's sending active mode packets and responds with passive mode packets similarly to a server in the client/server mode. Generally, peers send packets in their own interval and each packet is a request and response at the same time. The peers don't even have to use the same interval. One peer can be sending packets at a faster rate then the other and the protocol should still work. The client/server mode can be described as a special case of the symmetric mode, but they are not the same. > 6. NTP packets are already protected against replay attacks so DTLS does > not provide any additional protection. Not in the symmetric mode. The problem is that the packets are requests and responses at the same time. Replaying an older packet can disrupt the NTP state of the peer (as it cannot remember all packets that have been sent) and cause a denial of service. The issue was described in http://eprint.iacr.org/2016/1006. Please see the appendix B. The peers could require that each received packet has a newer timestamp, but that would not allow backward steps and it would still not prevent attacks in cases like when a peer has no RTC and starts in 1970, but the other peer thinks it's a timestamp from 2106 (in the next NTP era). As I understand it, wrapping NTP packets in DTLS would fix this issue. However, the use of a different transport for NTP timing messages would create few other issues and that's why it was removed from the latest version of the draft. > 8. The response packet can be smaller than the request packet. For that > matter if the response is slightly larger then it does not qualify as an > amplification in the security sense. I have actual use cases which would > make the response smaller. Can you provide some examples? NTP packets generally need to have a symmetric length in order to not create an asymmetric delay, so if there are such cases, padding the response or request should be recommended to not break the symmetry. -- Miroslav Lichvar From nobody Mon Nov 6 04:37: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 EFE4A13FBED for ; Mon, 6 Nov 2017 04:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4l7bs-2Iu9q for ; Mon, 6 Nov 2017 04:37:10 -0800 (PST) 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 1CF7913FB57 for ; Mon, 6 Nov 2017 04:37:10 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C26B849035; Mon, 6 Nov 2017 12:37:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C26B849035 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.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 D901D5D9C7; Mon, 6 Nov 2017 12:37:08 +0000 (UTC) Date: Mon, 6 Nov 2017 13:36:44 +0100 From: Miroslav Lichvar To: Tal Mizrahi Cc: ntp@ietf.org, Aanchal Malhotra Message-ID: <20171106123644.GA16738@localhost> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> <20171031155717.GC7648@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 06 Nov 2017 12:37:09 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 12:37:11 -0000 On Wed, Nov 01, 2017 at 11:41:26AM +0200, Tal Mizrahi wrote: > Small correction: > Slow-to-fast cut-through is *not* possible. > Fast-to-slow cut-through *is* possible. Do you know if there are any switches that actually support it? I suspect the buffering would be a major complication for a relatively small improvement in the overall latency. If a switch cut through from a faster link to a slower link, it would know the length of the packet and could calculate the (negative) correction before the correction field was transmitted, right? I assume that the field is in the second half of the packet and the ratio between the speeds is at least 2:1. I think the draft can specify that the correction needs to be calculated from the end of the reception and beginning of the transmission if the link speeds are different. If the speeds are equal, it can be any combination of beginning/end of the reception/transmission, because a symmetric correction will be made in the opposite direction. The delay will be different, but there won't be any asymmetry. Does that make sense? > > On Tue, Oct 31, 2017 at 5:57 PM, Miroslav Lichvar > > wrote: > > > >> On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote: > >> > Moreover, we never know which nodes along the path use > >> store-and-forward, > >> > and which nodes use cut-through. In cut-through forwarding the packet > >> > transmission may start before the last bit is received, so it certainly > >> > makes more sense to measure the first-bit-in-to-first-bit-out. > >> > >> That's a good point. With cut-through switching the correction would > >> be negative and generally couldn't be determined in time to be put in > >> the packet as the length is unknown. Are there any switches that can > >> cut-through from a faster link to slower link? > >> > >> Maybe it would make sense to allow corrections from preamble RX > >> timestamps when the link speeds are equal. -- Miroslav Lichvar From nobody Wed Nov 8 09:32:19 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 219111293FF for ; Wed, 8 Nov 2017 09:32:18 -0800 (PST) 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, 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=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 VQHIg9tBpD5Z for ; Wed, 8 Nov 2017 09:32:16 -0800 (PST) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 DA7D1129477 for ; Wed, 8 Nov 2017 09:32:08 -0800 (PST) Received: by mail-ot0-x244.google.com with SMTP id s88so2965738ota.4 for ; Wed, 08 Nov 2017 09:32:08 -0800 (PST) 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=YIsbiT9rLG++//jgL4nBkvsiPYyr3fAeIyMOWaxb+PU=; b=oxEHpebvCcFs9KxLYmI7IDr/Fba6Zc402oqZzn0Oh1Hn4cqoZTn4oJCE/ooGcDd/7d GdcAFYb5IlH731VC8RFGOXhNdi0EswNJ3LX3lo/S7nJGU3LQougSXIZQu2+Gsj47Xfmi qvinqiKAplMbI2DBq+PL1AFhFY/hWqZ6Pwnc7FDmblTbkqLqZMwwIfvxj/mlSzIG0uif 6QPrbXqhcLlfb7rgFaXcyzWjKYHCG/YFJxWpAgPCHeBgxoUzScurPfANuBsu5CUEsMxN 35vREsG+jxCIT/GWbGnpfB95c51xHmtawopXl6ibJct9/0fyJMQldGwrUbrB+HzMRIW6 hHeg== 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=YIsbiT9rLG++//jgL4nBkvsiPYyr3fAeIyMOWaxb+PU=; b=dIYbc9DBlD89nwo/rEXcKeabNS0qZbd1maZopZ3FfOzJn0CjVzApMj8408JjL9YTy8 o+wggZ9VRfjgj4PLl/sCBKIJ8BewJnCE8RQFEaKf/ALRQvx1cK7mOXA29KBj60zmFcts 0BMUN3oB5GJdl4RSKJSc/G2Y/ffjaOovayYZDVdM5Q/eTiah+OeoXruDzQh9YV5lXEYP Ei/i3hXbNSEcVpS1vMMciGf+hs1i/RWuGCzsd0Mp+y4MTkFPrvO7UsN+s6KT9rO+AaIk X2Wlk6zU5byzUgtHxYbkSjOesYubxqWYxMR/ge4r5w8BoGk1eMGcSgwoeWZrLmOb7zQT 120w== X-Gm-Message-State: AJaThX4l1ddyf6J4F+gKSRQD80rh2n2gG6aOc8j+j/dHAYOAlGQ5wH2M JnkJAxQizRl4V2oEDdFLdcpB4W79/BWFmhtlE7AYEA== X-Google-Smtp-Source: AGs4zMZ5zAbuk0c1kvK67WPEFkuGaf/G1/AcnzPcH7r13ZOoJIgDCHknOc8Iejpum9ldsIswhFvOAKeac3BjWPBMG58= X-Received: by 10.157.47.145 with SMTP id r17mr775884otb.108.1510162328316; Wed, 08 Nov 2017 09:32:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.168.25.194 with HTTP; Wed, 8 Nov 2017 09:32:07 -0800 (PST) In-Reply-To: <20171106123644.GA16738@localhost> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> <20171031155717.GC7648@localhost> <20171106123644.GA16738@localhost> From: Tal Mizrahi Date: Wed, 8 Nov 2017 19:32:07 +0200 Message-ID: To: Miroslav Lichvar Cc: ntp@ietf.org, Aanchal Malhotra Content-Type: multipart/alternative; boundary="001a113cf8c221f408055d7c1184" Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 17:32:18 -0000 --001a113cf8c221f408055d7c1184 Content-Type: text/plain; charset="UTF-8" Hi Miroslav, > Do you know if there are any switches that actually support it? Yes, some switches actually support it fast-to-slow cut-through. >If a switch cut through from a faster link to a slower link, it would >know the length of the packet and could calculate the (negative) >correction before the correction field was transmitted, right? Hmmm... So the switch would have to evaluate the packet length based on the Length field in the UDP header, and use that in the correction field computation. It would be significantly easier to implement a correction field computation based on first-bit-in-to-first-bit-out. I may be missing something here, but I would argue that if we consistently compute the correction based on first-bit-in-to-first-bit-out, the packet transmission times on both directions would cancel out, and would not affect the symmetry of the computation. Can you provide an example in which this hypothesis is wrong? Thanks, Tal. On Mon, Nov 6, 2017 at 2:36 PM, Miroslav Lichvar wrote: > On Wed, Nov 01, 2017 at 11:41:26AM +0200, Tal Mizrahi wrote: > > Small correction: > > Slow-to-fast cut-through is *not* possible. > > Fast-to-slow cut-through *is* possible. > > Do you know if there are any switches that actually support it? I > suspect the buffering would be a major complication for a relatively > small improvement in the overall latency. > > If a switch cut through from a faster link to a slower link, it would > know the length of the packet and could calculate the (negative) > correction before the correction field was transmitted, right? I > assume that the field is in the second half of the packet and the > ratio between the speeds is at least 2:1. > > I think the draft can specify that the correction needs to be > calculated from the end of the reception and beginning of the > transmission if the link speeds are different. If the speeds are > equal, it can be any combination of beginning/end of the > reception/transmission, because a symmetric correction will be made in > the opposite direction. The delay will be different, but there won't > be any asymmetry. > > Does that make sense? > > > > On Tue, Oct 31, 2017 at 5:57 PM, Miroslav Lichvar > > > > wrote: > > > > > >> On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote: > > >> > Moreover, we never know which nodes along the path use > > >> store-and-forward, > > >> > and which nodes use cut-through. In cut-through forwarding the > packet > > >> > transmission may start before the last bit is received, so it > certainly > > >> > makes more sense to measure the first-bit-in-to-first-bit-out. > > >> > > >> That's a good point. With cut-through switching the correction would > > >> be negative and generally couldn't be determined in time to be put in > > >> the packet as the length is unknown. Are there any switches that can > > >> cut-through from a faster link to slower link? > > >> > > >> Maybe it would make sense to allow corrections from preamble RX > > >> timestamps when the link speeds are equal. > > -- > Miroslav Lichvar > --001a113cf8c221f408055d7c1184 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Miroslav,

>=C2=A0Do you know if t= here are any switches that actually support it?

Ye= s, some switches actually support it fast-to-slow cut-through.
>If a switch cut through from a faster link to a slowe= r link, it would
>know the length of the packet and could calc= ulate the (negative)
>correction before the correction field w= as transmitted, right?

Hmmm... So the switch= would have to evaluate the packet length based on the Length field in the = UDP header, and use that in the correction field computation.
It = would be significantly easier to implement a correction field computation b= ased on first-bit-in-to-first-bit-out.


<= div>I may be missing something here, but I would argue that if we consisten= tly compute the correction based on first-bit-in-to-first-bit-out, the pack= et transmission times on both directions would cancel out, and would not af= fect the symmetry of the computation.
Can you provide an example = in which this hypothesis is wrong?

Thanks,
Tal.



On Mon, Nov 6, 2017 at 2:36 PM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
On Wed, Nov 01, 2017 at 11:41:= 26AM +0200, Tal Mizrahi wrote:
> Small correction:
> Slow-to-fast cut-through is *not* possible.
> Fast-to-slow cut-through *is* possible.

Do you know if there are any switches that actually support it? I suspect the buffering would be a major complication for a relatively
small improvement in the overall latency.

If a switch cut through from a faster link to a slower link, it would
know the length of the packet and could calculate the (negative)
correction before the correction field was transmitted, right? I
assume that the field is in the second half of the packet and the
ratio between the speeds is at least 2:1.

I think the draft can specify that the correction needs to be
calculated from the end of the reception and beginning of the
transmission if the link speeds are different. If the speeds are
equal, it can be any combination of beginning/end of the
reception/transmission, because a symmetric correction will be made in
the opposite direction. The delay will be different, but there won't be any asymmetry.

Does that make sense?

> > On Tue, Oct 31, 2017 at 5:57 PM, Miroslav Lichvar <mlichvar@redhat.com>
> > wrote:
> >
> >> On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote:<= br>
> >> &g= t; Moreover, we never know which nodes along the path use
> >> store-and-forward,
> >> > and which nodes use cut-through. In cut-through forwardi= ng the packet
> >> > transmission may start before the last bit is received, = so it certainly
> >> > makes more sense to measure the first-bit-in-to-first-bi= t-out.
> >>
> >> That's a good point. With cut-through switching the corre= ction would
> >> be negative and generally couldn't be determined in time = to be put in
> >> the packet as the length is unknown. Are there any switches t= hat can
> >> cut-through from a faster link to slower link?
> >>
> >> Maybe it would make sense to allow corrections from preamble = RX
> >> timestamps when the link speeds are equal.

--
Miroslav Lichvar

--001a113cf8c221f408055d7c1184-- From nobody Thu Nov 9 01:38: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 AA75C12ECC6 for ; Thu, 9 Nov 2017 01:38:57 -0800 (PST) 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 bw3EVycbNCKL for ; Thu, 9 Nov 2017 01:38:55 -0800 (PST) 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 946FE12ECA9 for ; Thu, 9 Nov 2017 01:38:54 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 54FB4683F5; Thu, 9 Nov 2017 09:38:54 +0000 (UTC) Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6D3785FFF1; Thu, 9 Nov 2017 09:38:53 +0000 (UTC) Date: Thu, 9 Nov 2017 10:38:51 +0100 From: Miroslav Lichvar To: Tal Mizrahi Cc: ntp@ietf.org, Aanchal Malhotra Message-ID: <20171109093851.GA17365@localhost> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> <20171031155717.GC7648@localhost> <20171106123644.GA16738@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 09 Nov 2017 09:38:54 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 09:38:58 -0000 On Wed, Nov 08, 2017 at 07:32:07PM +0200, Tal Mizrahi wrote: > >If a switch cut through from a faster link to a slower link, it would > >know the length of the packet and could calculate the (negative) > >correction before the correction field was transmitted, right? > > Hmmm... So the switch would have to evaluate the packet length based on the > Length field in the UDP header, and use that in the correction field > computation. Good point. Using the UDP length field should be simpler and give the switch more time to calculate the correction than waiting for the end of the received frame. > It would be significantly easier to implement a correction field > computation based on first-bit-in-to-first-bit-out. I understand that. The question is if it's worth the incompatibility that it would create. > I may be missing something here, but I would argue that if we consistently > compute the correction based on first-bit-in-to-first-bit-out, the packet > transmission times on both directions would cancel out, and would not > affect the symmetry of the computation. Yes, but only if the client, server and all switches with different link speeds between them used the beginning of the reception too. The clients and servers would have to switch between two modes of timestamping. One for networks where the correction fields is not supported and one for networks where all switches (with different link speeds) support it. It's all or nothing. On the other hand, a correction field based on the end of the reception is compatible with timestamping used by existing clients and servers, and a gradual replacement of switches in the network does not create an asymmetry. > Can you provide an example in which this hypothesis is wrong? Ok, let's say there is a server on 100 Mbit link, a client on a 1000 Mbit link, and a single switch (store-and-forward) between them. The propagation delay is 100 nanoseconds on both links and the switch has a constant asymmetric delay of 500/1000 nanoseconds. The client sends a 1000 bit frame at time X and the server responds with a frame of the same length at Y. All timestamping is perfectly accurate. The intervals of the receptions and transmissions are: client TX: [X, X+1000] switch RX: [X+100, X+1100] switch TX: [X+1600, X+11600] server RX: [X+1700, X+11700] server TX: [Y, Y+10000] switch RX: [Y+100, Y+10100] switch TX: [Y+11100, Y+12100] client RX: [Y+11200, Y+12200] If the correction field was ignored, the delays of the request and response would be 11700 and 12200 nanoseconds respectively. The calculated offset would have an error of 250 nanoseconds. If the switch calculated the corrections from the beginning of the receptions, the delays would be 10200 and 1200 nanoseconds. The error in the offset would be 4500 nanoseconds. If the switch calculated the corrections from the end of the reception, the delays would be 11200 and 11200 nanoseconds. The offset would have no error. This shows that the switch has to timestamp the same point of the frame as the server and client. Otherwise, the correction field may actually increase the error in the measured offset. -- Miroslav Lichvar From nobody Thu Nov 9 05:11:56 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FE01242F5 for ; Thu, 9 Nov 2017 05:11:55 -0800 (PST) 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 6Eo_WujxyDLh for ; Thu, 9 Nov 2017 05:11:48 -0800 (PST) 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 2CFF6124234 for ; Thu, 9 Nov 2017 05:11:48 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id g125so4339915oib.12 for ; Thu, 09 Nov 2017 05:11:48 -0800 (PST) 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=xwBKTcuB96De7HU/XvMmrHg1fYG/r6+/JGLbk/CRQZ4=; b=juzVG6nWmNFzvva5fvk5TnpqvVjw2vk0CJw4Ocy6Z7maKX/sGwWtprfSHajzjR0cWN SbQHSrq/sqcKA9wIjpaBoAl9V4DacjoNalI/rOhcKns67J+6Vq9YFLe48Pz4+sLrW2Vt kVkxpn1VvR6wbm75YG54OQzMgzpxLK5opolbPQlMWazVQ59m1WDPBsSAGV/RfIecQIaG LeOR3f4StWxvlSjKjAWPMQvuoRjLsZmIGEpgUI1G/B0xiRdFYcC1BrvQ5xNvP86/mFzl K9BLOKpLn/O9ZF0BDH71b9sNzkretvJ46+VyFNhSv5lAmj4MpXxHYanz5fpqqsHtNbiK H9KA== 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=xwBKTcuB96De7HU/XvMmrHg1fYG/r6+/JGLbk/CRQZ4=; b=RqAMgv+GbU3G8gWz9QASgoih7gU+CLR38hqZySNe6x0F9dFfyK8Avl6MYwQcABHEv+ /SSIQgRkI+W+COBgyJTfEO/ilI4Qr5SINwALhqMMv3N9O66I0inO5tj7qUpjr/MLIR0+ 5uajF6kFJlakIflRAcCtY+An4lvHbrgvBhPjt+NXBrnyxmX4wMEAST1eqK5JYSoKVUkX aj5sjpJfgMDCDP+hLluUGB5HRb6andu2wJYnogSGZ645pcQanhZpJoFISKNJjygilA7b wUIKWQ8oT+3qFFGv7IhwM7wTRUx3FeiYTr/D1ogl4r+aox65eSiQHmm8Gs9bAf2DCdpR ZA5w== X-Gm-Message-State: AJaThX6y/FX8TKDbk+JgMI0GfMz/QVtb5SAwJBJH16BvGW4idfZRoV73 nbxYEk1nNmqnrtUlG9I5cJy+ftYvI3frwh36URM= X-Google-Smtp-Source: AGs4zMbW8B6qzc2y8UVLzPaNDXUZfL78yB8mUejZGc7hYO8otu4RL6q/SvXpycFb7Qfxbr8sNFitY+y5eVBtK7A3Pb0= X-Received: by 10.202.232.8 with SMTP id f8mr259777oih.186.1510233107345; Thu, 09 Nov 2017 05:11:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.168.25.194 with HTTP; Thu, 9 Nov 2017 05:11:46 -0800 (PST) In-Reply-To: <20171109093851.GA17365@localhost> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> <20171031155717.GC7648@localhost> <20171106123644.GA16738@localhost> <20171109093851.GA17365@localhost> From: Tal Mizrahi Date: Thu, 9 Nov 2017 15:11:46 +0200 Message-ID: To: Miroslav Lichvar Cc: ntp@ietf.org, Aanchal Malhotra Content-Type: multipart/alternative; boundary="001a1140828ee435be055d8c8b2f" Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 13:11:55 -0000 --001a1140828ee435be055d8c8b2f Content-Type: text/plain; charset="UTF-8" Hi Miroslav, Very nice example. It clarifies your point. I believe the inconsistency you raised here could be resolved if both the client and server would measure all timestamps as the time-of-the-first-bit (both reception and transmission). If that would be the case, then (using your example): Client TX timestamp = X Switch (client->server) correction field = 1500 Server RX timestamp = X+1700 Server TX timestamp = Y Switch (server->client) correction field = 11000 Client RX timestamp = Y+11200 In this case the client would compute the delay on both directions to be 200 nanoseconds, as desired. Again this all works only if the client / server use the first bit as the reference for both TX and RX timestamps. Cheers, Tal. On Thu, Nov 9, 2017 at 11:38 AM, Miroslav Lichvar wrote: > On Wed, Nov 08, 2017 at 07:32:07PM +0200, Tal Mizrahi wrote: > > >If a switch cut through from a faster link to a slower link, it would > > >know the length of the packet and could calculate the (negative) > > >correction before the correction field was transmitted, right? > > > > Hmmm... So the switch would have to evaluate the packet length based on > the > > Length field in the UDP header, and use that in the correction field > > computation. > > Good point. Using the UDP length field should be simpler and give the > switch more time to calculate the correction than waiting for the > end of the received frame. > > > It would be significantly easier to implement a correction field > > computation based on first-bit-in-to-first-bit-out. > > I understand that. The question is if it's worth the incompatibility > that it would create. > > > I may be missing something here, but I would argue that if we > consistently > > compute the correction based on first-bit-in-to-first-bit-out, the packet > > transmission times on both directions would cancel out, and would not > > affect the symmetry of the computation. > > Yes, but only if the client, server and all switches with different > link speeds between them used the beginning of the reception too. > > The clients and servers would have to switch between two modes of > timestamping. One for networks where the correction fields is not > supported and one for networks where all switches (with different link > speeds) support it. It's all or nothing. > > On the other hand, a correction field based on the end of the > reception is compatible with timestamping used by existing clients and > servers, and a gradual replacement of switches in the network does not > create an asymmetry. > > > Can you provide an example in which this hypothesis is wrong? > > Ok, let's say there is a server on 100 Mbit link, a client on a 1000 > Mbit link, and a single switch (store-and-forward) between them. The > propagation delay is 100 nanoseconds on both links and the switch has > a constant asymmetric delay of 500/1000 nanoseconds. The client sends > a 1000 bit frame at time X and the server responds with a frame of the > same length at Y. All timestamping is perfectly accurate. > > The intervals of the receptions and transmissions are: > > client TX: [X, X+1000] > switch RX: [X+100, X+1100] > switch TX: [X+1600, X+11600] > server RX: [X+1700, X+11700] > server TX: [Y, Y+10000] > switch RX: [Y+100, Y+10100] > switch TX: [Y+11100, Y+12100] > client RX: [Y+11200, Y+12200] > > If the correction field was ignored, the delays of the request and > response would be 11700 and 12200 nanoseconds respectively. The > calculated offset would have an error of 250 nanoseconds. > > If the switch calculated the corrections from the beginning of the > receptions, the delays would be 10200 and 1200 nanoseconds. The error > in the offset would be 4500 nanoseconds. > > If the switch calculated the corrections from the end of the > reception, the delays would be 11200 and 11200 nanoseconds. The offset > would have no error. > > This shows that the switch has to timestamp the same point of the > frame as the server and client. Otherwise, the correction field may > actually increase the error in the measured offset. > > -- > Miroslav Lichvar > --001a1140828ee435be055d8c8b2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Miroslav,

Very nice example.=C2=A0
It clarifies your point.

I believe the in= consistency you raised here could be resolved if both the client and server= would measure all timestamps as the time-of-the-first-bit (both reception = and transmission).
If that would be the case, then (using your ex= ample):

Client TX timestamp =3D X
Switch= (client->server) correction field =3D 1500
Server RX timestam= p =3D X+1700

Server TX timestamp =3D Y
S= witch (server->client) correction field =3D 11000
Client RX ti= mestamp =3D Y+11200

In this case the client would = compute the delay on both directions to be 200 nanoseconds, as desired.
Again this all works only if the client / server use the first bit a= s the reference for both TX and RX timestamps.

Cheers,
Tal.


On Thu, Nov 9, 2017 at 11:38 AM, Miroslav = Lichvar <mlichvar@redhat.com> wrote:
On Wed, Nov 08, 2017 at 07:32:07PM +0200, Ta= l Mizrahi wrote:
> >If a switch cut through from a faster link to a slower link, it wo= uld
> >know the length of the packet and could calculate the (negative) > >correction before the correction field was transmitted, right?
>
> Hmmm... So the switch would have to evaluate the packet length based o= n the
> Length field in the UDP header, and use that in the correction field > computation.

Good point. Using the UDP length field should be simpler and give th= e
switch more time to calculate the correction than waiting for the
end of the received frame.

> It would be significantly easier to implement a correction field
> computation based on first-bit-in-to-first-bit-out.

I understand that. The question is if it's worth the incompatibi= lity
that it would create.

> I may be missing something here, but I would argue that if we consiste= ntly
> compute the correction based on first-bit-in-to-first-bit-out, the pac= ket
> transmission times on both directions would cancel out, and would not<= br> > affect the symmetry of the computation.

Yes, but only if the client, server and all switches with different<= br> link speeds between them used the beginning of the reception too.

The clients and servers would have to switch between two modes of
timestamping. One for networks where the correction fields is not
supported and one for networks where all switches (with different link
speeds) support it. It's all or nothing.

On the other hand, a correction field based on the end of the
reception is compatible with timestamping used by existing clients and
servers, and a gradual replacement of switches in the network does not
create an asymmetry.

> Can you provide an example in which this hypothesis is wrong?

Ok, let's say there is a server on 100 Mbit link, a client on a = 1000
Mbit link, and a single switch (store-and-forward) between them. The
propagation delay is 100 nanoseconds on both links and the switch has
a constant asymmetric delay of 500/1000 nanoseconds. The client sends
a 1000 bit frame at time X and the server responds with a frame of the
same length at Y. All timestamping is perfectly accurate.

The intervals of the receptions and transmissions are:

client TX: [X, X+1000]
switch RX: [X+100, X+1100]
switch TX: [X+1600, X+11600]
server RX: [X+1700, X+11700]
server TX: [Y, Y+10000]
switch RX: [Y+100, Y+10100]
switch TX: [Y+11100, Y+12100]
client RX: [Y+11200, Y+12200]

If the correction field was ignored, the delays of the request and
response would be 11700 and 12200 nanoseconds respectively. The
calculated offset would have an error of 250 nanoseconds.

If the switch calculated the corrections from the beginning of the
receptions, the delays would be 10200 and 1200 nanoseconds. The error
in the offset would be 4500 nanoseconds.

If the switch calculated the corrections from the end of the
reception, the delays would be 11200 and 11200 nanoseconds. The offset
would have no error.

This shows that the switch has to timestamp the same point of the
frame as the server and client. Otherwise, the correction field may
actually increase the error in the measured offset.

--
Miroslav Lichvar

--001a1140828ee435be055d8c8b2f-- From nobody Thu Nov 9 08:19: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 6065D126557 for ; Thu, 9 Nov 2017 08:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=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 4mbtEzssOQ2P for ; Thu, 9 Nov 2017 08:19:26 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0047.outbound.protection.outlook.com [104.47.36.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD35124D85 for ; Thu, 9 Nov 2017 08:19:26 -0800 (PST) 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=7Gu4pnEveVRo31anRfV0Wgy3+nqKDOJiaW8IcvxVaXg=; b=kc/OfhZs6Z8sUfAsJcLHvhxGyT+x3CgUtOgb1O9xASxJKbpWTdngdjwCZ4ZoDCkDDy5XlT9eoUySFp3phLEiGE1K4Kv/f1lILxtkbQAW5xCQqeAVEVhevdRosG8erCDUJg/56pGdHhBz74/qO6PIYy4FkdRFiZjVUKljYyckZyI= Received: from MWHPR0201CA0103.namprd02.prod.outlook.com (10.167.161.44) by BY2PR0201MB0741.namprd02.prod.outlook.com (10.160.124.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Thu, 9 Nov 2017 16:19:22 +0000 Received: from BY2FFO11OLC005.protection.gbl (2a01:111:f400:7c0c::143) by MWHPR0201CA0103.outlook.office365.com (2603:10b6:301:75::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.218.12 via Frontend Transport; Thu, 9 Nov 2017 16:19:22 +0000 Authentication-Results: spf=pass (sender IP is 208.19.100.20) smtp.mailfrom=microsemi.com; bu.edu; dkim=none (message not signed) header.d=none;bu.edu; dmarc=bestguesspass action=none header.from=microsemi.com; Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.20 as permitted sender) receiver=protection.outlook.com; client-ip=208.19.100.20; helo=avsrvexchhts2.microsemi.net; Received: from avsrvexchhts2.microsemi.net (208.19.100.20) by BY2FFO11OLC005.mail.protection.outlook.com (10.1.14.145) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.178.5 via Frontend Transport; Thu, 9 Nov 2017 16:19:20 +0000 Received: from AVMBX1.microsemi.net (10.100.34.31) by avsrvexchhts2.microsemi.net (10.100.34.106) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 9 Nov 2017 08:18:15 -0800 Received: from AVMBX1.microsemi.net (10.100.34.31) by AVMBX1.microsemi.net (10.100.34.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1261.35; Thu, 9 Nov 2017 08:18:14 -0800 Received: from SJSRVEXCHHTS1.microsemi.net (10.241.34.105) by avmbx1.microsemi.net (10.100.34.31) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Thu, 9 Nov 2017 08:18:14 -0800 Received: from SJSRVEXCHMBX2.microsemi.net ([fe80::6da0:6f9d:d5d1:3d5d]) by sjsrvexchhts1.microsemi.net ([::1]) with mapi id 14.03.0361.001; Thu, 9 Nov 2017 08:18:12 -0800 From: Greg Dowd To: Tal Mizrahi , Miroslav Lichvar CC: Aanchal Malhotra , "ntp@ietf.org" Thread-Topic: [Ntp] Drafts on interleaved modes and correction field Thread-Index: AQHTUibko2qH9HHhdE6MN2nq8y+qG6L+TuIAgAAhOYCAABK/AIAAEAqAgAD5FwCAADA7AIAIHWYAgAN3MoCAAQ4agIAAO30A//+pxuA= Date: Thu, 9 Nov 2017 16:18:12 +0000 Message-ID: <8D2BF679AAC7C346848A489074F9F8BFF353D0C4@sjsrvexchmbx2.microsemi.net> References: <20171031090139.GD15597@localhost> <20171031135247.GB7648@localhost> <20171031155717.GC7648@localhost> <20171106123644.GA16738@localhost> <20171109093851.GA17365@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.128.48] Content-Type: multipart/alternative; boundary="_000_8D2BF679AAC7C346848A489074F9F8BFF353D0C4sjsrvexchmbx2mi_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:208.19.100.20; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(2980300002)(438002)(76104003)(199003)(24454002)(189002)(106466001)(86362001)(39060400002)(54906003)(7736002)(6246003)(2900100001)(106002)(2920100001)(316002)(6306002)(9686003)(54896002)(356003)(72206003)(236005)(33656002)(16586007)(53546010)(53416004)(53936002)(93886005)(110136005)(7696004)(97736004)(229853002)(5250100002)(2950100002)(54356999)(6116002)(50986999)(55846006)(3846002)(49446005)(790700001)(69596002)(76176999)(102836003)(2906002)(512874002)(84326002)(8936002)(5660300001)(81156014)(68736007)(478600001)(81166006)(189998001)(4326008)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0201MB0741; H:avsrvexchhts2.microsemi.net; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC005; 1:z3ldhEJE5hBYHkd8ldvzJxlC2eE83awP0AK0O78kD/JM/mAYzYrWYwYGY4ytMyHkXXJ7T+sQAxUmMGhTBXZEehcmVQylkImx5utgz7UaPi4UUypu/4zWKgkX3KSP/oYv X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6799c1b9-1c40-40de-7319-08d5278da2be X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:BY2PR0201MB0741; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0201MB0741; 3:QHwEqbF4HZ9sCr8Frv6WNKzmzUFHtcL6sGd484/29m2rYtZ4k20KM2aiI7QpNhEIVevaZouiJxQ5ZW3yH1VdOgxI7JEBFV9rWX2ooVeI4tB2HnB8TMdonbtU6Oc3BH3DmpmYG8/zoGrvJaR9P+nATjIdIxqwpNULSEZV5yhBi6B0PQV/KQJwL35vlxgqX+eUO5G/ROzyfjhCnyNEjrwEfW+1SAeogQC/PI9udt+V02l02Nwz0H/otUx1LiHVALYZ+OiWm+NrygL53ANQeEp8noxY7YqH0ehImVHVDhTD14RLpgJmJV6uvua9MMzfD6uFz5eOM1PBhTuAMwcmqgk93jwryDZ1DQOxC1HRclTwK5s=; 25:zPGhxLPcp71Ye+8vn7ILJIcQ6h2AWbZ9mF7lV+xgSGvezk0f0CyBJMzx+HxnU1UWoBuQA1KnK/PhpKynlg2RVAle5zrFYe8aBmtyr2cS6YHY9AFx1cf/SVbbH3PsCWqizlTGyXKXK8sbYpU9n6ehDv8Ew7QniuyWrxySozNfhYpZsg9KXWk7K/CI7vaJ4ZjB2WFQ48mjKGiodV4ro86kI74hDlgqrEtYgp2SRUM28QaHVwWvDuSIHXiAfbDN9uV9VNc1zA1SHqjoxl+VjbNoI55bpnDg5BJipomhepOH2NuTyjHrS7OO5kwBMNUC/N9kZ4dyKe1emFJRT5lIcxcAyw== X-MS-TrafficTypeDiagnostic: BY2PR0201MB0741: X-Microsoft-Exchange-Diagnostics: 1; BY2PR0201MB0741; 31:9DbA/WbZXulqAdljH6K6Nj96MkU7fHleOJbHb/tG/yOAEPACaqHg/x0iwqhGuzUNJo32MhmgrPOtuaF64PQiFXGD4JuvgswaUTA/ae0dJgxLlUDdpeh5IsWGT+sIWI52/JGueIY2I+oTlRk/7OYUj13OG7dyhxTLDZC89tGgaDM2/vqpCqy9s5EDl36CCiits3w+oZ0rdG3gm1oqCi2yuDuud/A1iPg7u5NyMgbjTBA=; 20:5CSXa2lcwgNFIy+qo4ZjLhEHqSPrmTPDkkyEP/L/7j/CL454zvsjzE+S4pPJ1rCV7ysomAPBpxmuW8Rof1EDcCVTtOu12AYe7Dq6e81rI5ZpM35PcahFN4l5gCxcMIEis/My/mswyv1OWaL4BZRTXH/UMXGgXbgN4Yjvxv+Rb5xnd/XuenEH7pspjkK7ECbQN+zheF8e1F3rzASGA174jN62E2aGiIPH2rAsMoY8vwQuQjW7yZkLEUlvnedC5lqnJgofRARNqVyNu6cBufn/817RLGhB6lVD59Yw9xYD6TzwbkF7egRIzErxgZLR40I42DDMXRWo8HHSET/OCUACImMlLQomhOkTRlD1oXOV1u3z3vl27QJhus7yHIpyGgXQm2qGxfc7zwoGe3yDKuQiB3BXJiKMBTRv8m7Wi6xvDKJ5cH3HKaGOGOHV2NKUkqSiDkpI+EKV5Gsyv1qO0iaLfHFPDttJpRCSN6ylDWhjQBO+31EnCF+UNUkNLokwqTNL X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(238701278423138)(21748063052155); 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)(3231021)(3002001)(93006095)(93004095)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR0201MB0741; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR0201MB0741; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0201MB0741; 4:BzsHG2wlCpEz5FGM5dzYVMZxI0ykSit6JtZ9JMAeIx9F3vo0W8L0Et+kvfrLqz4qV8ataW26XsE1o8jeZNYt85ze/CPUf5GUGD6oGkjfkxyungmlGHgP9Yk00BfFngAN3Ie3ghAYd1qh1bGNPeVR4auXKNyyMT15ZV4wS5QEAeeBUeIcegF4qLl2e3JTdb4rGAmjjRuG7CCwH8QkhfeeFgIjATBsR36lCLkVvrC2fk6bI3DsqraOsb1VeJoPU7HVYOrcg5LrdnpvrLoSjQk7qCDMPvhzNXPRLrADYDRfOXixKmnvr9F7ZsPLP8jqTZjcVHOmwvSqxRocVdpWAHZNXqcNTpj+VkjuIYqQO9jS4a5gf17hjnSGnbSkqOVqD0Rh X-Forefront-PRVS: 0486A0CB86 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0201MB0741; 23:KsREg6Mwxt7sBOfRtz6ZamDJ255QAsExECbbRDD?= =?us-ascii?Q?sv2CN0LUjw8E4CC0iPIxtC41w2raYuE5ASlNqEhZMzi9zsRWQV+BGyNhJPhF?= =?us-ascii?Q?U7F3hUCxCHrB/QDtrOvOKi7Wukz3O03/U08FfVGSFKp7IE4OOC4zlE2e6cen?= =?us-ascii?Q?8emqukJo6/+9SFeX4pfBXoTTMw42l8ByvE4PydP5K7547horZvuvt9wAX6n6?= =?us-ascii?Q?NHlhQBLEbdXtewNuYxbvevupa6iYNA9BJfMvs0yBB5ndMGxuT94g30ZUUZIM?= =?us-ascii?Q?H6GqeCoctV+NCybwpXLFtzqQ9/jukH9FcLR12fPznPbN6xK8ChU9k2MUDgb1?= =?us-ascii?Q?sZXBY3p8qizZgvZcUMuMf814/fCIhSa+v2YKhIrik1uWDCb/5NvsF8Nl/0sQ?= =?us-ascii?Q?yFDLjQRT13OwNpTuZodnxoMnBMF0nSwoESiQGn9r17fgfdBUgJkotYPSZqTC?= =?us-ascii?Q?ptDr99BnibtNPoG2ZnX1F32V7AKbdoEm9tcqASOk2CyiR3CC95aK21TMqb7H?= =?us-ascii?Q?o9Wwo0a1AZkbSuKDRiKKk8qNI6y902scKjtDWn4LRPsKT5SZe+yWh4fm6O4v?= =?us-ascii?Q?5IB3+y9HtxwrR7FIED0VOirR/KtaeiHNbsFTM1RNFX5xLLb1z/YunWbfdKbR?= =?us-ascii?Q?hxAm76VgWdRnZROOpNgJXdyC/PQs+GIW1Htn0JEqVuhjloZTBxHqwNG2Ws5p?= =?us-ascii?Q?tlITG2w818Vg+Q2qv0g38Nche99IbJFYrpvyVOdBj/FSRxTfgnnc0Rd+xBDz?= =?us-ascii?Q?knntswkdGWMYTVJrL/PMvBth3uIYJeKvvmZwWCq0ThD4r4NnGLHu04bYJAdQ?= =?us-ascii?Q?3WVv4iBTZ05MjgIEI0909yWhkhB3DQlanLnG/ohSy/PH8Zf4bamrUBiLz0Xa?= =?us-ascii?Q?8OQZutTqy8huZiOL8KxKN5K8eM0omsERTRe51+xHeABY+EgkEwH2pl/5Irv7?= =?us-ascii?Q?RmXoP+CA5c0ORZ+a5P0F1eGAFVQevCd/qX33gSbwc0dVVZ0z1/nZmizqimlL?= =?us-ascii?Q?LB9RoLp76uPKby2pCU92ncPBdfEfCIeF7o8hkI20klBXxvKSvgz9dVaQLfqC?= =?us-ascii?Q?fNt2boru9p6EdW1+TaicXzKnfLBsfZ2ngD1vCIkwNDI1kSQhODU9fqowMzLa?= =?us-ascii?Q?ZlYjFXlB+Ew0Weh8SLfBN3vz9qFTJzeHfc1BfGw3+BuCVKN0DGrI+yfl7+/j?= =?us-ascii?Q?ZuU3pkhdDQYA8KuW0llIPZb0ALkoRyZGnnGLfsShiGsmy1v9BIBjQgpe58MM?= =?us-ascii?Q?nJgkxCk8kWTJmfFL9dov2HoHXjP3nUk5r0fo/DXPu4Zct+4s0qn9LOk6+6Im?= =?us-ascii?Q?yjYmaA+MrbuX0VOpSNnxjgQE9q2mSTB+16reMyk7GdT8gJBiPya+OqtXgjLa?= =?us-ascii?Q?2BgqlIqV/h1lVgHbanlkX3JlVSrk=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0201MB0741; 6:muSNSgrBICnQ1QC1YC1I3UGgoiqknwe3rQYraA34s3gvil9Z3R6PE84orUfWIlVMhyxbk3gGw6RSW3wTsVO91q2k4OlsGOMiE/KPSVzHjWWVnKpUbLIOrpIDhWdGeeY/FtbkbrVIVwnhH1wCEiUSt6QK8kDWp5DjTjbquKC5P+8gHPTLwwpH64MazR2GwelW6ZIVtgM1wEiUNmjMpO1kUreqBDnN1HJ+WXi1Zfe/T+HKZibLpjyLxqYKjqxzqRDSdkHzXWjNnPQaeoNtbsFZ7j9lATrjAqlqUvY7KGLK/6KR5UzOz4fHUzS3zZxwDQyEbZawYjSJ0C446IeN97yC9+PbAyOVD19FvQA3vmlvxik=; 5:aJBSv+IWPhUMpii8BuTSbvuPmkFe3rML2T98ipWHXbFnqx83y/uAu3rkK4da5myJCcKoNa+wgl2fK0qTcyQBN+Uq68JjufxgLg4niUaZOcOJ6opeCT2Lfc7HpeqIM0UPi7QhoHA5NYJPgmshalO6JZ+jb2+nTXvtwAWZcSsKDOk=; 24:DKEvtx7/jmYP/T6+Y9bQXY81eOXddM6yGzOwU4cxR/vPJmn1Q/fvXq+12XU5N/vV1yx0Ysj68tu6wdx438UHfiTGkLd+H4JP9GO2PyyLl08=; 7:cKOyEoAKwsyjVn6rnt9ydtsryEB2Yd0QbBh3UAw+mPqFA1OsaYtI1O2Yp/ExfQftKBHWYPy9ik7aM19d/v6Jz5IqLSsHjDbYkg7ZSP0cmall1rQaJV4bvsx0ApLwSyqs0xuRhM3WkilMRblvOrUuGJDBFT2pcEvUPhLywfIjyP0vc9zmUHNfoNoXqeqkvrzb9BqYN1WkK+kWrmCWUQPZo+UTwDI8cv7x1SNjkxRve2shUcYhnzW7qJUhxTk4OrL9 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsemi.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2017 16:19:20.2547 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6799c1b9-1c40-40de-7319-08d5278da2be X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.20]; Helo=[avsrvexchhts2.microsemi.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB0741 Archived-At: Subject: Re: [Ntp] Drafts on interleaved modes and correction field X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:19:29 -0000 --_000_8D2BF679AAC7C346848A489074F9F8BFF353D0C4sjsrvexchmbx2mi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSByZWNhbGwsIHRoaXMgYWxsIHdvcmtzIGlmIGV2ZXJ5IGRldmljZSBpbiB0aGUgbmV0d29y ayBhcmUgdGltZXN0YW1wIGNvcnJlY3Rpb24gYXdhcmUuICBUYWwsIEkgdGhpbmsgeW91IGhhdmUg cHJvYmFibHkgYmVlbiBpbnZvbHZlZCBpbiBtYW55IGRpc2N1c3Npb25zIG9mIHRoaXMgdHlwZSwg LiAgSSB0ZW5kIHRvIGJlbGlldmUgdGhhdCBPU0kgbW9kZWwgaW1wbGllcyB0aGF0IHdlIHNob3Vs ZCBub3QgYmUgdG9vIGZvY3VzZWQgb24gc3BlY2lmeWluZyB3aGljaCBiaXQgb2Ygd2hpY2ggc3lt Ym9sIGlzIHNlbGVjdGVkLg0KDQpNeSByZWNvbW1lbmRhdGlvbiBpcyB0aGF0IHdlIGNhbGwgb3V0 IHNvbWV0aGluZyBsaWtlIDgwMi4zYmYgKD8pIGFuZCBwcm92aWRlIGV4YW1wbGVzIG9mIHRoZSBh c3ltbWV0cnkvaW1wbGVtZW50YXRpb24gaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBzZWxlY3Rpb25z LiAgVGhlIHJlYWxpdHkgaXMgdGhhdCB0aW1lc3RhbXBzIGFyZSBzdHJ1Y2sgYW5kIGFyZSDigJxm aXhlZCB1cOKAnSB0byBiZSBTT0ggb3IgRVRCIGluIGhhcmR3YXJlIGFueXdheS4gIFRoZSBjdXJy ZW50IE5UUCBwcm90b2NvbCBoYXMgYWxyZWFkeSBkZWZpbmVkIHRoZSDigJxkZWZhdWx04oCdIGFz IGJlZ2lubmluZyBvZiB0eC9lbmQgb2YgcnggaGlzdG9yaWNhbGx5Lg0KDQpXaGF0IGRvIHlvdSB0 aGluaz8NCg0KVGhhbmtz4oCmR3JlZw0KDQoNCg0KDQoNCkZyb206IG50cCBbbWFpbHRvOm50cC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGFsIE1penJhaGkNClNlbnQ6IFRodXJzZGF5 LCBOb3ZlbWJlciA5LCAyMDE3IDU6MTIgQU0NClRvOiBNaXJvc2xhdiBMaWNodmFyIDxtbGljaHZh ckByZWRoYXQuY29tPg0KQ2M6IEFhbmNoYWwgTWFsaG90cmEgPGFhbmNoYWw0QGJ1LmVkdT47IG50 cEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtOdHBdIERyYWZ0cyBvbiBpbnRlcmxlYXZlZCBtb2Rl cyBhbmQgY29ycmVjdGlvbiBmaWVsZA0KDQpFWFRFUk5BTCBFTUFJTA0KSGkgTWlyb3NsYXYsDQoN ClZlcnkgbmljZSBleGFtcGxlLg0KSXQgY2xhcmlmaWVzIHlvdXIgcG9pbnQuDQoNCkkgYmVsaWV2 ZSB0aGUgaW5jb25zaXN0ZW5jeSB5b3UgcmFpc2VkIGhlcmUgY291bGQgYmUgcmVzb2x2ZWQgaWYg Ym90aCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgd291bGQgbWVhc3VyZSBhbGwgdGltZXN0YW1wcyBh cyB0aGUgdGltZS1vZi10aGUtZmlyc3QtYml0IChib3RoIHJlY2VwdGlvbiBhbmQgdHJhbnNtaXNz aW9uKS4NCklmIHRoYXQgd291bGQgYmUgdGhlIGNhc2UsIHRoZW4gKHVzaW5nIHlvdXIgZXhhbXBs ZSk6DQoNCkNsaWVudCBUWCB0aW1lc3RhbXAgPSBYDQpTd2l0Y2ggKGNsaWVudC0+c2VydmVyKSBj b3JyZWN0aW9uIGZpZWxkID0gMTUwMA0KU2VydmVyIFJYIHRpbWVzdGFtcCA9IFgrMTcwMA0KDQpT ZXJ2ZXIgVFggdGltZXN0YW1wID0gWQ0KU3dpdGNoIChzZXJ2ZXItPmNsaWVudCkgY29ycmVjdGlv biBmaWVsZCA9IDExMDAwDQpDbGllbnQgUlggdGltZXN0YW1wID0gWSsxMTIwMA0KDQpJbiB0aGlz IGNhc2UgdGhlIGNsaWVudCB3b3VsZCBjb21wdXRlIHRoZSBkZWxheSBvbiBib3RoIGRpcmVjdGlv bnMgdG8gYmUgMjAwIG5hbm9zZWNvbmRzLCBhcyBkZXNpcmVkLg0KQWdhaW4gdGhpcyBhbGwgd29y a3Mgb25seSBpZiB0aGUgY2xpZW50IC8gc2VydmVyIHVzZSB0aGUgZmlyc3QgYml0IGFzIHRoZSBy ZWZlcmVuY2UgZm9yIGJvdGggVFggYW5kIFJYIHRpbWVzdGFtcHMuDQoNCkNoZWVycywNClRhbC4N Cg0KDQpPbiBUaHUsIE5vdiA5LCAyMDE3IGF0IDExOjM4IEFNLCBNaXJvc2xhdiBMaWNodmFyIDxt bGljaHZhckByZWRoYXQuY29tPG1haWx0bzptbGljaHZhckByZWRoYXQuY29tPj4gd3JvdGU6DQpP biBXZWQsIE5vdiAwOCwgMjAxNyBhdCAwNzozMjowN1BNICswMjAwLCBUYWwgTWl6cmFoaSB3cm90 ZToNCj4gPklmIGEgc3dpdGNoIGN1dCB0aHJvdWdoIGZyb20gYSBmYXN0ZXIgbGluayB0byBhIHNs b3dlciBsaW5rLCBpdCB3b3VsZA0KPiA+a25vdyB0aGUgbGVuZ3RoIG9mIHRoZSBwYWNrZXQgYW5k IGNvdWxkIGNhbGN1bGF0ZSB0aGUgKG5lZ2F0aXZlKQ0KPiA+Y29ycmVjdGlvbiBiZWZvcmUgdGhl IGNvcnJlY3Rpb24gZmllbGQgd2FzIHRyYW5zbWl0dGVkLCByaWdodD8NCj4NCj4gSG1tbS4uLiBT byB0aGUgc3dpdGNoIHdvdWxkIGhhdmUgdG8gZXZhbHVhdGUgdGhlIHBhY2tldCBsZW5ndGggYmFz ZWQgb24gdGhlDQo+IExlbmd0aCBmaWVsZCBpbiB0aGUgVURQIGhlYWRlciwgYW5kIHVzZSB0aGF0 IGluIHRoZSBjb3JyZWN0aW9uIGZpZWxkDQo+IGNvbXB1dGF0aW9uLg0KDQpHb29kIHBvaW50LiBV c2luZyB0aGUgVURQIGxlbmd0aCBmaWVsZCBzaG91bGQgYmUgc2ltcGxlciBhbmQgZ2l2ZSB0aGUN CnN3aXRjaCBtb3JlIHRpbWUgdG8gY2FsY3VsYXRlIHRoZSBjb3JyZWN0aW9uIHRoYW4gd2FpdGlu ZyBmb3IgdGhlDQplbmQgb2YgdGhlIHJlY2VpdmVkIGZyYW1lLg0KDQo+IEl0IHdvdWxkIGJlIHNp Z25pZmljYW50bHkgZWFzaWVyIHRvIGltcGxlbWVudCBhIGNvcnJlY3Rpb24gZmllbGQNCj4gY29t cHV0YXRpb24gYmFzZWQgb24gZmlyc3QtYml0LWluLXRvLWZpcnN0LWJpdC1vdXQuDQoNCkkgdW5k ZXJzdGFuZCB0aGF0LiBUaGUgcXVlc3Rpb24gaXMgaWYgaXQncyB3b3J0aCB0aGUgaW5jb21wYXRp YmlsaXR5DQp0aGF0IGl0IHdvdWxkIGNyZWF0ZS4NCg0KPiBJIG1heSBiZSBtaXNzaW5nIHNvbWV0 aGluZyBoZXJlLCBidXQgSSB3b3VsZCBhcmd1ZSB0aGF0IGlmIHdlIGNvbnNpc3RlbnRseQ0KPiBj b21wdXRlIHRoZSBjb3JyZWN0aW9uIGJhc2VkIG9uIGZpcnN0LWJpdC1pbi10by1maXJzdC1iaXQt b3V0LCB0aGUgcGFja2V0DQo+IHRyYW5zbWlzc2lvbiB0aW1lcyBvbiBib3RoIGRpcmVjdGlvbnMg d291bGQgY2FuY2VsIG91dCwgYW5kIHdvdWxkIG5vdA0KPiBhZmZlY3QgdGhlIHN5bW1ldHJ5IG9m IHRoZSBjb21wdXRhdGlvbi4NCg0KWWVzLCBidXQgb25seSBpZiB0aGUgY2xpZW50LCBzZXJ2ZXIg YW5kIGFsbCBzd2l0Y2hlcyB3aXRoIGRpZmZlcmVudA0KbGluayBzcGVlZHMgYmV0d2VlbiB0aGVt IHVzZWQgdGhlIGJlZ2lubmluZyBvZiB0aGUgcmVjZXB0aW9uIHRvby4NCg0KVGhlIGNsaWVudHMg YW5kIHNlcnZlcnMgd291bGQgaGF2ZSB0byBzd2l0Y2ggYmV0d2VlbiB0d28gbW9kZXMgb2YNCnRp bWVzdGFtcGluZy4gT25lIGZvciBuZXR3b3JrcyB3aGVyZSB0aGUgY29ycmVjdGlvbiBmaWVsZHMg aXMgbm90DQpzdXBwb3J0ZWQgYW5kIG9uZSBmb3IgbmV0d29ya3Mgd2hlcmUgYWxsIHN3aXRjaGVz ICh3aXRoIGRpZmZlcmVudCBsaW5rDQpzcGVlZHMpIHN1cHBvcnQgaXQuIEl0J3MgYWxsIG9yIG5v dGhpbmcuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBhIGNvcnJlY3Rpb24gZmllbGQgYmFzZWQgb24g dGhlIGVuZCBvZiB0aGUNCnJlY2VwdGlvbiBpcyBjb21wYXRpYmxlIHdpdGggdGltZXN0YW1waW5n IHVzZWQgYnkgZXhpc3RpbmcgY2xpZW50cyBhbmQNCnNlcnZlcnMsIGFuZCBhIGdyYWR1YWwgcmVw bGFjZW1lbnQgb2Ygc3dpdGNoZXMgaW4gdGhlIG5ldHdvcmsgZG9lcyBub3QNCmNyZWF0ZSBhbiBh c3ltbWV0cnkuDQoNCj4gQ2FuIHlvdSBwcm92aWRlIGFuIGV4YW1wbGUgaW4gd2hpY2ggdGhpcyBo eXBvdGhlc2lzIGlzIHdyb25nPw0KDQpPaywgbGV0J3Mgc2F5IHRoZXJlIGlzIGEgc2VydmVyIG9u IDEwMCBNYml0IGxpbmssIGEgY2xpZW50IG9uIGEgMTAwMA0KTWJpdCBsaW5rLCBhbmQgYSBzaW5n bGUgc3dpdGNoIChzdG9yZS1hbmQtZm9yd2FyZCkgYmV0d2VlbiB0aGVtLiBUaGUNCnByb3BhZ2F0 aW9uIGRlbGF5IGlzIDEwMCBuYW5vc2Vjb25kcyBvbiBib3RoIGxpbmtzIGFuZCB0aGUgc3dpdGNo IGhhcw0KYSBjb25zdGFudCBhc3ltbWV0cmljIGRlbGF5IG9mIDUwMC8xMDAwIG5hbm9zZWNvbmRz LiBUaGUgY2xpZW50IHNlbmRzDQphIDEwMDAgYml0IGZyYW1lIGF0IHRpbWUgWCBhbmQgdGhlIHNl cnZlciByZXNwb25kcyB3aXRoIGEgZnJhbWUgb2YgdGhlDQpzYW1lIGxlbmd0aCBhdCBZLiBBbGwg dGltZXN0YW1waW5nIGlzIHBlcmZlY3RseSBhY2N1cmF0ZS4NCg0KVGhlIGludGVydmFscyBvZiB0 aGUgcmVjZXB0aW9ucyBhbmQgdHJhbnNtaXNzaW9ucyBhcmU6DQoNCmNsaWVudCBUWDogW1gsIFgr MTAwMF0NCnN3aXRjaCBSWDogW1grMTAwLCBYKzExMDBdDQpzd2l0Y2ggVFg6IFtYKzE2MDAsIFgr MTE2MDBdDQpzZXJ2ZXIgUlg6IFtYKzE3MDAsIFgrMTE3MDBdDQpzZXJ2ZXIgVFg6IFtZLCBZKzEw MDAwXQ0Kc3dpdGNoIFJYOiBbWSsxMDAsIFkrMTAxMDBdDQpzd2l0Y2ggVFg6IFtZKzExMTAwLCBZ KzEyMTAwXQ0KY2xpZW50IFJYOiBbWSsxMTIwMCwgWSsxMjIwMF0NCg0KSWYgdGhlIGNvcnJlY3Rp b24gZmllbGQgd2FzIGlnbm9yZWQsIHRoZSBkZWxheXMgb2YgdGhlIHJlcXVlc3QgYW5kDQpyZXNw b25zZSB3b3VsZCBiZSAxMTcwMCBhbmQgMTIyMDAgbmFub3NlY29uZHMgcmVzcGVjdGl2ZWx5LiBU aGUNCmNhbGN1bGF0ZWQgb2Zmc2V0IHdvdWxkIGhhdmUgYW4gZXJyb3Igb2YgMjUwIG5hbm9zZWNv bmRzLg0KDQpJZiB0aGUgc3dpdGNoIGNhbGN1bGF0ZWQgdGhlIGNvcnJlY3Rpb25zIGZyb20gdGhl IGJlZ2lubmluZyBvZiB0aGUNCnJlY2VwdGlvbnMsIHRoZSBkZWxheXMgd291bGQgYmUgMTAyMDAg YW5kIDEyMDAgbmFub3NlY29uZHMuIFRoZSBlcnJvcg0KaW4gdGhlIG9mZnNldCB3b3VsZCBiZSA0 NTAwIG5hbm9zZWNvbmRzLg0KDQpJZiB0aGUgc3dpdGNoIGNhbGN1bGF0ZWQgdGhlIGNvcnJlY3Rp b25zIGZyb20gdGhlIGVuZCBvZiB0aGUNCnJlY2VwdGlvbiwgdGhlIGRlbGF5cyB3b3VsZCBiZSAx MTIwMCBhbmQgMTEyMDAgbmFub3NlY29uZHMuIFRoZSBvZmZzZXQNCndvdWxkIGhhdmUgbm8gZXJy b3IuDQoNClRoaXMgc2hvd3MgdGhhdCB0aGUgc3dpdGNoIGhhcyB0byB0aW1lc3RhbXAgdGhlIHNh bWUgcG9pbnQgb2YgdGhlDQpmcmFtZSBhcyB0aGUgc2VydmVyIGFuZCBjbGllbnQuIE90aGVyd2lz ZSwgdGhlIGNvcnJlY3Rpb24gZmllbGQgbWF5DQphY3R1YWxseSBpbmNyZWFzZSB0aGUgZXJyb3Ig aW4gdGhlIG1lYXN1cmVkIG9mZnNldC4NCg0KLS0NCk1pcm9zbGF2IExpY2h2YXINCg0K --_000_8D2BF679AAC7C346848A489074F9F8BFF353D0C4sjsrvexchmbx2mi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYW1icmlhOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpi DQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIHJlY2FsbCwgdGhpcyBhbGwg d29ya3MgaWYgZXZlcnkgZGV2aWNlIGluIHRoZSBuZXR3b3JrIGFyZSB0aW1lc3RhbXAgY29ycmVj dGlvbiBhd2FyZS4mbmJzcDsgVGFsLCBJIHRoaW5rIHlvdSBoYXZlIHByb2JhYmx5IGJlZW4gaW52 b2x2ZWQgaW4gbWFueSBkaXNjdXNzaW9ucyBvZiB0aGlzIHR5cGUsIC4mbmJzcDsgSSB0ZW5kIHRv IGJlbGlldmUgdGhhdCBPU0kgbW9kZWwgaW1wbGllcyB0aGF0IHdlIHNob3VsZCBub3QgYmUNCiB0 b28gZm9jdXNlZCBvbiBzcGVjaWZ5aW5nIHdoaWNoIGJpdCBvZiB3aGljaCBzeW1ib2wgaXMgc2Vs ZWN0ZWQuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSByZWNvbW1lbmRhdGlvbiBp cyB0aGF0IHdlIGNhbGwgb3V0IHNvbWV0aGluZyBsaWtlIDgwMi4zYmYgKD8pIGFuZCBwcm92aWRl IGV4YW1wbGVzIG9mIHRoZSBhc3ltbWV0cnkvaW1wbGVtZW50YXRpb24gaXNzdWVzIGFzc29jaWF0 ZWQgd2l0aCBzZWxlY3Rpb25zLiZuYnNwOyBUaGUgcmVhbGl0eSBpcyB0aGF0IHRpbWVzdGFtcHMg YXJlIHN0cnVjayBhbmQgYXJlIOKAnGZpeGVkIHVw4oCdIHRvIGJlIFNPSCBvciBFVEIgaW4gaGFy ZHdhcmUNCiBhbnl3YXkuJm5ic3A7IFRoZSBjdXJyZW50IE5UUCBwcm90b2NvbCBoYXMgYWxyZWFk eSBkZWZpbmVkIHRoZSDigJxkZWZhdWx04oCdIGFzIGJlZ2lubmluZyBvZiB0eC9lbmQgb2Ygcngg aGlzdG9yaWNhbGx5Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG8geW91IHRoaW5r PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3PigKZHcmVnIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gbnRwIFttYWlsdG86bnRwLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9i PlRhbCBNaXpyYWhpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciA5LCAyMDE3 IDU6MTIgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pcm9zbGF2IExpY2h2YXIgJmx0O21saWNodmFyQHJl ZGhhdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBYW5jaGFsIE1hbGhvdHJhICZsdDthYW5jaGFs NEBidS5lZHUmZ3Q7OyBudHBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOdHBd IERyYWZ0cyBvbiBpbnRlcmxlYXZlZCBtb2RlcyBhbmQgY29ycmVjdGlvbiBmaWVsZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYW1i cmlhJnF1b3Q7LHNlcmlmO2NvbG9yOnJlZCI+RVhURVJOQUwgRU1BSUw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1pcm9zbGF2LCA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZlcnkgbmljZSBl eGFtcGxlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgY2xhcmlmaWVzIHlvdXIgcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGUgaW5jb25zaXN0ZW5j eSB5b3UgcmFpc2VkIGhlcmUgY291bGQgYmUgcmVzb2x2ZWQgaWYgYm90aCB0aGUgY2xpZW50IGFu ZCBzZXJ2ZXIgd291bGQgbWVhc3VyZSBhbGwgdGltZXN0YW1wcyBhcyB0aGUgdGltZS1vZi10aGUt Zmlyc3QtYml0IChib3RoIHJlY2VwdGlvbiBhbmQgdHJhbnNtaXNzaW9uKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoYXQgd291bGQgYmUg dGhlIGNhc2UsIHRoZW4gKHVzaW5nIHlvdXIgZXhhbXBsZSk6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNsaWVudCBUWCB0aW1lc3RhbXAgPSBY PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Td2l0 Y2ggKGNsaWVudC0mZ3Q7c2VydmVyKSBjb3JyZWN0aW9uIGZpZWxkID0gMTUwMDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VydmVyIFJYIHRpbWVz dGFtcCA9IFgmIzQzOzE3MDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U2VydmVyIFRYIHRpbWVzdGFtcCA9IFk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN3aXRjaCAoc2VydmVyLSZndDtjbGll bnQpIGNvcnJlY3Rpb24gZmllbGQgPSAxMTAwMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xpZW50IFJYIHRpbWVzdGFtcCA9IFkmIzQzOzExMjAw PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IHRoaXMgY2FzZSB0aGUgY2xpZW50IHdvdWxkIGNvbXB1dGUgdGhlIGRlbGF5IG9uIGJvdGggZGly ZWN0aW9ucyB0byBiZSAyMDAgbmFub3NlY29uZHMsIGFzIGRlc2lyZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2FpbiB0aGlzIGFsbCB3b3Jr cyBvbmx5IGlmIHRoZSBjbGllbnQgLyBzZXJ2ZXIgdXNlIHRoZSBmaXJzdCBiaXQgYXMgdGhlIHJl ZmVyZW5jZSBmb3IgYm90aCBUWCBhbmQgUlggdGltZXN0YW1wcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFsLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTm92IDks IDIwMTcgYXQgMTE6MzggQU0sIE1pcm9zbGF2IExpY2h2YXIgJmx0OzxhIGhyZWY9Im1haWx0bzpt bGljaHZhckByZWRoYXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWxpY2h2YXJAcmVkaGF0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE5vdiAw OCwgMjAxNyBhdCAwNzozMjowN1BNICYjNDM7MDIwMCwgVGFsIE1penJhaGkgd3JvdGU6PGJyPg0K Jmd0OyAmZ3Q7SWYgYSBzd2l0Y2ggY3V0IHRocm91Z2ggZnJvbSBhIGZhc3RlciBsaW5rIHRvIGEg c2xvd2VyIGxpbmssIGl0IHdvdWxkPGJyPg0KJmd0OyAmZ3Q7a25vdyB0aGUgbGVuZ3RoIG9mIHRo ZSBwYWNrZXQgYW5kIGNvdWxkIGNhbGN1bGF0ZSB0aGUgKG5lZ2F0aXZlKTxicj4NCiZndDsgJmd0 O2NvcnJlY3Rpb24gYmVmb3JlIHRoZSBjb3JyZWN0aW9uIGZpZWxkIHdhcyB0cmFuc21pdHRlZCwg cmlnaHQ/PGJyPg0KJmd0Ozxicj4NCiZndDsgSG1tbS4uLiBTbyB0aGUgc3dpdGNoIHdvdWxkIGhh dmUgdG8gZXZhbHVhdGUgdGhlIHBhY2tldCBsZW5ndGggYmFzZWQgb24gdGhlPGJyPg0KJmd0OyBM ZW5ndGggZmllbGQgaW4gdGhlIFVEUCBoZWFkZXIsIGFuZCB1c2UgdGhhdCBpbiB0aGUgY29ycmVj dGlvbiBmaWVsZDxicj4NCiZndDsgY29tcHV0YXRpb24uPGJyPg0KPGJyPg0KR29vZCBwb2ludC4g VXNpbmcgdGhlIFVEUCBsZW5ndGggZmllbGQgc2hvdWxkIGJlIHNpbXBsZXIgYW5kIGdpdmUgdGhl PGJyPg0Kc3dpdGNoIG1vcmUgdGltZSB0byBjYWxjdWxhdGUgdGhlIGNvcnJlY3Rpb24gdGhhbiB3 YWl0aW5nIGZvciB0aGU8YnI+DQplbmQgb2YgdGhlIHJlY2VpdmVkIGZyYW1lLjxicj4NCjxicj4N CiZndDsgSXQgd291bGQgYmUgc2lnbmlmaWNhbnRseSBlYXNpZXIgdG8gaW1wbGVtZW50IGEgY29y cmVjdGlvbiBmaWVsZDxicj4NCiZndDsgY29tcHV0YXRpb24gYmFzZWQgb24gZmlyc3QtYml0LWlu LXRvLWZpcnN0LWJpdC1vdXQuPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5kIHRoYXQuIFRoZSBxdWVz dGlvbiBpcyBpZiBpdCdzIHdvcnRoIHRoZSBpbmNvbXBhdGliaWxpdHk8YnI+DQp0aGF0IGl0IHdv dWxkIGNyZWF0ZS48YnI+DQo8YnI+DQomZ3Q7IEkgbWF5IGJlIG1pc3Npbmcgc29tZXRoaW5nIGhl cmUsIGJ1dCBJIHdvdWxkIGFyZ3VlIHRoYXQgaWYgd2UgY29uc2lzdGVudGx5PGJyPg0KJmd0OyBj b21wdXRlIHRoZSBjb3JyZWN0aW9uIGJhc2VkIG9uIGZpcnN0LWJpdC1pbi10by1maXJzdC1iaXQt b3V0LCB0aGUgcGFja2V0PGJyPg0KJmd0OyB0cmFuc21pc3Npb24gdGltZXMgb24gYm90aCBkaXJl Y3Rpb25zIHdvdWxkIGNhbmNlbCBvdXQsIGFuZCB3b3VsZCBub3Q8YnI+DQomZ3Q7IGFmZmVjdCB0 aGUgc3ltbWV0cnkgb2YgdGhlIGNvbXB1dGF0aW9uLjxicj4NCjxicj4NClllcywgYnV0IG9ubHkg aWYgdGhlIGNsaWVudCwgc2VydmVyIGFuZCBhbGwgc3dpdGNoZXMgd2l0aCBkaWZmZXJlbnQ8YnI+ DQpsaW5rIHNwZWVkcyBiZXR3ZWVuIHRoZW0gdXNlZCB0aGUgYmVnaW5uaW5nIG9mIHRoZSByZWNl cHRpb24gdG9vLjxicj4NCjxicj4NClRoZSBjbGllbnRzIGFuZCBzZXJ2ZXJzIHdvdWxkIGhhdmUg dG8gc3dpdGNoIGJldHdlZW4gdHdvIG1vZGVzIG9mPGJyPg0KdGltZXN0YW1waW5nLiBPbmUgZm9y IG5ldHdvcmtzIHdoZXJlIHRoZSBjb3JyZWN0aW9uIGZpZWxkcyBpcyBub3Q8YnI+DQpzdXBwb3J0 ZWQgYW5kIG9uZSBmb3IgbmV0d29ya3Mgd2hlcmUgYWxsIHN3aXRjaGVzICh3aXRoIGRpZmZlcmVu dCBsaW5rPGJyPg0Kc3BlZWRzKSBzdXBwb3J0IGl0LiBJdCdzIGFsbCBvciBub3RoaW5nLjxicj4N Cjxicj4NCk9uIHRoZSBvdGhlciBoYW5kLCBhIGNvcnJlY3Rpb24gZmllbGQgYmFzZWQgb24gdGhl IGVuZCBvZiB0aGU8YnI+DQpyZWNlcHRpb24gaXMgY29tcGF0aWJsZSB3aXRoIHRpbWVzdGFtcGlu ZyB1c2VkIGJ5IGV4aXN0aW5nIGNsaWVudHMgYW5kPGJyPg0Kc2VydmVycywgYW5kIGEgZ3JhZHVh bCByZXBsYWNlbWVudCBvZiBzd2l0Y2hlcyBpbiB0aGUgbmV0d29yayBkb2VzIG5vdDxicj4NCmNy ZWF0ZSBhbiBhc3ltbWV0cnkuPGJyPg0KPGJyPg0KJmd0OyBDYW4geW91IHByb3ZpZGUgYW4gZXhh bXBsZSBpbiB3aGljaCB0aGlzIGh5cG90aGVzaXMgaXMgd3Jvbmc/PGJyPg0KPGJyPg0KT2ssIGxl dCdzIHNheSB0aGVyZSBpcyBhIHNlcnZlciBvbiAxMDAgTWJpdCBsaW5rLCBhIGNsaWVudCBvbiBh IDEwMDA8YnI+DQpNYml0IGxpbmssIGFuZCBhIHNpbmdsZSBzd2l0Y2ggKHN0b3JlLWFuZC1mb3J3 YXJkKSBiZXR3ZWVuIHRoZW0uIFRoZTxicj4NCnByb3BhZ2F0aW9uIGRlbGF5IGlzIDEwMCBuYW5v c2Vjb25kcyBvbiBib3RoIGxpbmtzIGFuZCB0aGUgc3dpdGNoIGhhczxicj4NCmEgY29uc3RhbnQg YXN5bW1ldHJpYyBkZWxheSBvZiA1MDAvMTAwMCBuYW5vc2Vjb25kcy4gVGhlIGNsaWVudCBzZW5k czxicj4NCmEgMTAwMCBiaXQgZnJhbWUgYXQgdGltZSBYIGFuZCB0aGUgc2VydmVyIHJlc3BvbmRz IHdpdGggYSBmcmFtZSBvZiB0aGU8YnI+DQpzYW1lIGxlbmd0aCBhdCBZLiBBbGwgdGltZXN0YW1w aW5nIGlzIHBlcmZlY3RseSBhY2N1cmF0ZS48YnI+DQo8YnI+DQpUaGUgaW50ZXJ2YWxzIG9mIHRo ZSByZWNlcHRpb25zIGFuZCB0cmFuc21pc3Npb25zIGFyZTo8YnI+DQo8YnI+DQpjbGllbnQgVFg6 IFtYLCBYJiM0MzsxMDAwXTxicj4NCnN3aXRjaCBSWDogW1gmIzQzOzEwMCwgWCYjNDM7MTEwMF08 YnI+DQpzd2l0Y2ggVFg6IFtYJiM0MzsxNjAwLCBYJiM0MzsxMTYwMF08YnI+DQpzZXJ2ZXIgUlg6 IFtYJiM0MzsxNzAwLCBYJiM0MzsxMTcwMF08YnI+DQpzZXJ2ZXIgVFg6IFtZLCBZJiM0MzsxMDAw MF08YnI+DQpzd2l0Y2ggUlg6IFtZJiM0MzsxMDAsIFkmIzQzOzEwMTAwXTxicj4NCnN3aXRjaCBU WDogW1kmIzQzOzExMTAwLCBZJiM0MzsxMjEwMF08YnI+DQpjbGllbnQgUlg6IFtZJiM0MzsxMTIw MCwgWSYjNDM7MTIyMDBdPGJyPg0KPGJyPg0KSWYgdGhlIGNvcnJlY3Rpb24gZmllbGQgd2FzIGln bm9yZWQsIHRoZSBkZWxheXMgb2YgdGhlIHJlcXVlc3QgYW5kPGJyPg0KcmVzcG9uc2Ugd291bGQg YmUgMTE3MDAgYW5kIDEyMjAwIG5hbm9zZWNvbmRzIHJlc3BlY3RpdmVseS4gVGhlPGJyPg0KY2Fs Y3VsYXRlZCBvZmZzZXQgd291bGQgaGF2ZSBhbiBlcnJvciBvZiAyNTAgbmFub3NlY29uZHMuPGJy Pg0KPGJyPg0KSWYgdGhlIHN3aXRjaCBjYWxjdWxhdGVkIHRoZSBjb3JyZWN0aW9ucyBmcm9tIHRo ZSBiZWdpbm5pbmcgb2YgdGhlPGJyPg0KcmVjZXB0aW9ucywgdGhlIGRlbGF5cyB3b3VsZCBiZSAx MDIwMCBhbmQgMTIwMCBuYW5vc2Vjb25kcy4gVGhlIGVycm9yPGJyPg0KaW4gdGhlIG9mZnNldCB3 b3VsZCBiZSA0NTAwIG5hbm9zZWNvbmRzLjxicj4NCjxicj4NCklmIHRoZSBzd2l0Y2ggY2FsY3Vs YXRlZCB0aGUgY29ycmVjdGlvbnMgZnJvbSB0aGUgZW5kIG9mIHRoZTxicj4NCnJlY2VwdGlvbiwg dGhlIGRlbGF5cyB3b3VsZCBiZSAxMTIwMCBhbmQgMTEyMDAgbmFub3NlY29uZHMuIFRoZSBvZmZz ZXQ8YnI+DQp3b3VsZCBoYXZlIG5vIGVycm9yLjxicj4NCjxicj4NClRoaXMgc2hvd3MgdGhhdCB0 aGUgc3dpdGNoIGhhcyB0byB0aW1lc3RhbXAgdGhlIHNhbWUgcG9pbnQgb2YgdGhlPGJyPg0KZnJh bWUgYXMgdGhlIHNlcnZlciBhbmQgY2xpZW50LiBPdGhlcndpc2UsIHRoZSBjb3JyZWN0aW9uIGZp ZWxkIG1heTxicj4NCmFjdHVhbGx5IGluY3JlYXNlIHRoZSBlcnJvciBpbiB0aGUgbWVhc3VyZWQg b2Zmc2V0Ljxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFz cz0iaG9lbnpiIj4tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5NaXJvc2xhdiBM aWNodmFyPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8D2BF679AAC7C346848A489074F9F8BFF353D0C4sjsrvexchmbx2mi_-- From nobody Mon Nov 13 01:23: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 AE991120713 for ; Mon, 13 Nov 2017 01:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 8UaKqS5StOT6 for ; Mon, 13 Nov 2017 01:22:57 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.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 09B7A127B5A for ; Mon, 13 Nov 2017 01:22:56 -0800 (PST) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vAD9LsAq004761-vAD9LsAs004761 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Nov 2017 10:21:54 +0100 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 33E825A9FB1 for ; Mon, 13 Nov 2017 10:21:54 +0100 (CET) To: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Mon, 13 Nov 2017 10:21:52 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00337192C12581D7_=" Archived-At: Subject: [Ntp] [NTP] Draft "On Implementing Time" 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, 13 Nov 2017 09:23:00 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00337192C12581D7_= Content-Type: text/plain; charset="US-ASCII" Hello all, I have just given a read to the "On Implementing Time" draft ( https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes ). There are a few issues that I'd like to raise. (1) Vocabulary (technical): use of the term "time" - Description: I take issue with not explaining what the document means when in uses the term "time", specifically "a time", when properties like continuous, monotonic (separate issue, see below) are assigned. In these cases, it is heavily implied the "a time" is supposed to be a function (because the cited properties are usually applied to functions), but this is never stated, which I find problematic. For example, I still need to figure out what the domain and co-domain of the function are supposed to be. Naively I would assume that the co-domain is a subset (probably implementation specific) of "int" or "float". I would then assume that the domain is... well, "actual" time. Which brings me to my next issue with the used terminology: "time" becomes an overloaded term, it represents the abstract heuristic concept and then also some kind of function from this concept to a machine-appropriate value set. - Suggested remedy: edit the terminology to be consistent, - Specific suggestions for the remedy (even if this is deemed insufficient, I still strongly advocate trying to implement the remedy in some other way): -- "Time" remains as the abstract heuristic concept (and is not explained in the document). -- The kind of value that a machine can read and communicate (for example a timestamp) could be called a "clocktime". The document should state this somewhere. How exactly "clocktime" is realized (int, float, ...) is implementation specific. The document might or might not go into that detail. -- The function that maps the current "time" to a "clocktime" is called a "clock". The document should state this somewhere. (2) Vocabulary (more editorial, with some technical implications): use of the term "continuous" - Description: since the co-domain of a "clock" (current term in the document is "time", see above) is necessarily a discrete set, the notion of "continuity" causes some problems, since the usual definitions don't easily apply (basically, the function always has "jumps" in it, due to the discrete nature of the co-domain). - Suggestion: clean up the terminology and make it consistent, OR just dumb it down. - Specific suggestion (clean-up): have "continuous" mean that the function does not exhibit jumps greater than the "resolution" of the co-domain. Use epsilon-delta definition, but loosen it to epsilon greater than or equal to . Note that this might require quite a lot of thougfht to get right. - Specific suggestion (dumb-down): simply state that "continuous" shall mean that the function "has no substantial jumps", or something along those lines. (3) Vocabulary (technical and editorial): use of the term "monotonic" - Description: Although I acknowledge that in 2.1, the draft gives a(n implicit) definition of what it refers to when it uses the term "monotonic" (i.e. "continuous and strictly monotonically increasing"), I still do not like it. The term monotonic has a specific meaning in mathematics (to be either monotonically increasing or monotonically decreasing), and I simply find it confusing to overload the term with a meaning that, on the one hand, adds a property (also means "continuous" now) and, on the other hand, removes one of the original options (cannot mean "monotonically decreasing" anymore). Stating that this terminology is "sometimes" used really doesn't help the issue, since I find it to be an obvious crutch notation. - Suggested remedy: come up with another term X instead of monotonic and replace the sentence by , modulo any potential changes in vocabulary for the term "time". If there is interest (if the current editors think it would make things easier and not harder), I guess I would offer to work on the draft as an additional editor. In any case, I think it is great that this kind of foundational work is being done, and I think it is worth investing quite a lot of time and thought, since there seems to be a severe lack of foundational content on issues.like these Best regards, Kristof --=_alternative 00337192C12581D7_= Content-Type: text/html; charset="US-ASCII" Hello all,

I have just given a read to the "On Implementing Time" draft (https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes).
There are a few issues that I'd like to raise.

(1) Vocabulary (technical): use of the term "time"
- Description: I take issue with not explaining what the document means when in uses the term "time", specifically "a <property> time", when properties like continuous, monotonic (separate issue, see below) are assigned. In these cases, it is heavily implied the "a time" is supposed to be a function (because the cited properties are usually applied to functions), but this is never stated, which I find problematic. For example, I still need to figure out what the domain and co-domain of the function are supposed to be. Naively I would assume that the co-domain is a subset (probably implementation specific) of "int" or "float". I would then assume that the domain is... well, "actual" time. Which brings me to my next issue with the used terminology: "time" becomes an overloaded term, it represents the abstract heuristic concept and then also some kind of function from this concept to a machine-appropriate value set.
- Suggested remedy: edit the terminology to be consistent,
- Specific suggestions for the remedy (even if this is deemed insufficient, I still strongly advocate trying to implement the remedy in some other way):
  -- "Time" remains as the abstract heuristic concept (and is not explained in the document).
  -- The kind of value that a machine can read and communicate (for example a timestamp) could be called a "clocktime". The document should state this somewhere. How exactly "clocktime" is realized (int, float, ...) is implementation specific. The document might or might not go into that detail.
  -- The function that maps the current "time" to a "clocktime" is called a "clock". The document should state this somewhere.

(2) Vocabulary (more editorial, with some technical implications): use of the term "continuous"
- Description: since the co-domain of a "clock" (current term in the document is "time", see above) is necessarily a discrete set, the notion of "continuity" causes some problems, since the usual definitions don't easily apply (basically, the function always has "jumps" in it, due to the discrete nature of the co-domain).
- Suggestion: clean up the terminology and make it consistent, OR just dumb it down.
- Specific suggestion (clean-up): have "continuous" mean that the function does not exhibit jumps greater than the "resolution" of the co-domain. Use epsilon-delta definition, but loosen it to epsilon greater than or equal to <resolution>. Note that this might require quite a lot of thougfht to get right.
- Specific suggestion (dumb-down): simply state that "continuous" shall mean that the function "has no substantial jumps", or something along those lines.

(3) Vocabulary (technical and editorial): use of the term "monotonic"
- Description: Although I acknowledge that in 2.1, the draft gives a(n implicit) definition of what it refers to when it uses the term "monotonic" (i.e. "continuous and strictly monotonically increasing"), I still do not like it. The term monotonic has a specific meaning in mathematics (to be either monotonically increasing or monotonically decreasing), and I simply find it confusing to overload the term with a meaning that, on the one hand, adds a property (also means "continuous" now) and, on the other hand, removes one of the original options (cannot mean "monotonically decreasing" anymore). Stating that this terminology is "sometimes" used really doesn't help the issue, since I find it to be an obvious crutch notation.
- Suggested remedy: come up with another term X instead of monotonic and replace the sentence <Such a time is sometimes called a "monotonic time."> by <We call such a time a [X] time.">, modulo any potential changes in vocabulary for the term "time".

If there is interest (if the current editors think it would make things easier and not harder), I guess I would offer to work on the draft as an additional editor.
In any case, I think it is great that this kind of foundational work is being done, and I think it is worth investing quite a lot of time and thought, since there seems to be a severe lack of foundational content on issues.like these


Best regards,
Kristof --=_alternative 00337192C12581D7_=-- From nobody Mon Nov 13 06:27: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 9D060129423 for ; Mon, 13 Nov 2017 06:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 je1mOvAaY2lX for ; Mon, 13 Nov 2017 06:27:13 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.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 74E96128C81 for ; Mon, 13 Nov 2017 06:27:13 -0800 (PST) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vADEQ9eg027913-vADEQ9ei027913 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 15:26:09 +0100 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id BCA335AA60C; Mon, 13 Nov 2017 15:26:09 +0100 (CET) To: ntp@ietf.org Cc: "Aanchal Malhotra" MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Mon, 13 Nov 2017 15:26:07 +0100 Content-Type: multipart/alternative; boundary="=_alternative 004F4C63C12581D7_=" Archived-At: Subject: [Ntp] Draft on Interleave Mode -- Keeping "preemptive" per-client state 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, 13 Nov 2017 14:27:15 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 004F4C63C12581D7_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 4oCLSGVsbG8gYWxsLA0KDQpJIHdhbnRlZCB0byBzdGFydC9yZXZpdmUgYSBkaXNjdXNzaW9uIGFi b3V0IHRoZSBpbnRlcmxlYXZlIG1vZGUgZGVzY3JpYmVkIA0KaW4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9wZGYvZHJhZnQtbWxpY2h2YXItbnRwLWludGVybGVhdmVkLW1vZGVzLTAwLnBkZi4NCg0K Q3VycmVudGx5LCB0aGUgYmVoYXZpb3JhbCBzY2hlbWUgZm9yIGEgc2VydmVyIHNlZW1zIHRvIGJl IHJvdWdobHkgdGhlIA0KZm9sbG93aW5nOg0KV2hlbmV2ZXIgYSBjbGllbnQgImJhc2ljIiByZXF1 ZXN0IGNvbWVzIGluLCB0aGUgc2VydmVyIGFuc3dlcnMgaXQgd2l0aCBhIA0KImJhc2ljIiByZXNw b25zZSAoc28gZmFyLCBzbyBvYnZpb3VzKSwgYnV0IGl0IGFkZGl0aW9uYWxseSBrZWVwcyBzdGF0 ZSBmb3IgDQp0aGlzIGFzc29jaWF0aW9uL3RoaXMgc3BlY2lmaWMgZXhjaGFuZ2UoPyksIGluIGNh c2UgdGhhdCB0aGVyZSBpcyBldmVyIA0KZ29pbmcgdG8gYmUgYW4gYWRkaXRpb25hbCBjbGllbnQg ImludGVybGVhdmUiIHJlcXVlc3QuIEFzIGxvbmcgYXMgdGhlIA0Kc2VydmVyIHdpc2hlcyB0byBv ZmZlciBpbnRlcmxlYXZlZCBtb2RlLCB0aGlzIGhhcHBlbnMgYWx3YXlzLCByZWdhcmRsZXNzIA0K b2YgbmVlZC4NClRoaXMgaXMgY29tcGxldGVseSByZWFzb25hYmxlIGlmIGl0IGNhbiBiZSBleHBl Y3RlZCB0aGF0IGV2ZXJ5ICJiYXNpYyIgDQpyZXF1ZXN0IChvciBhdCBsZWFzdCBhIHZlcnkgbGFy Z2UgcG9ydGlvbiBvZiB0aGVtKSB3aWxsIGV2ZW50dWFsbHkgYmUgDQpmb2xsb3dlZCB1cCB1cG9u IHdpdGggYW4gImludGVybGVhdmUiIHJlcXVlc3QuDQpJdCBkb2VzLCBob3dldmVyLCBzZWVtIGxp a2Ugc2VyaW91cyBvdmVya2lsbCBmb3IgYW55IGFzc29jaWF0aW9uIHdoZXJlIA0Kc3VjaCBhIGZv bGxvdy11cCBjYWxsIGNhbiBub3QgYmUgZXhwZWN0ZWQuDQoNCkkgd291bGQgdGhlcmVmb3JlIGFk dmlzZSBzb21lIGFkZGl0aW9uYWwgY29tbXVuaWNhdGlvbiwgdG8gZ2V0IHJpZCBvZiB0aGUgDQpj YXNlcyB3aGVyZSBzdGF0ZSBpcyBrZXB0IHVubmVjZXNzYXJpbHkuDQpXZSBjYW4gZ28gaW50byBz cGVjaWZpY3MgaWYgdGhlcmUgaXMgaW50ZXJlc3QsIGJ1dCBJIHdhbnRlZCB0byBrZWVwIHRoaXMg DQpkaXNjdXNzaW9uIHN0YXJ0ZXIgc2hvcnQuDQoNCg0KQmVzdCByZWdhcmRzLA0KS3Jpc3RvZg0K --=_alternative 004F4C63C12581D7_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zPuKAizwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SGVs bG8gYWxsLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ SSB3YW50ZWQgdG8gc3RhcnQvcmV2aXZlIGEgZGlzY3Vzc2lvbg0KYWJvdXQgdGhlIGludGVybGVh dmUgbW9kZSBkZXNjcmliZWQgaW4gPC9mb250PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvcGRmL2RyYWZ0LW1saWNodmFyLW50cC1pbnRlcmxlYXZlZC1tb2Rlcy0wMC5wZGYiPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvcGRmL2RyYWZ0LW1saWNodmFyLW50cC1pbnRlcmxlYXZlZC1tb2Rlcy0wMC5wZGY8L2ZvbnQ+ PC9hPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4uPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5DdXJyZW50bHksIHRoZSBiZWhhdmlvcmFsIHNj aGVtZSBmb3INCmEgc2VydmVyIHNlZW1zIHRvIGJlIHJvdWdobHkgdGhlIGZvbGxvd2luZzo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoZW5ldmVyIGEgY2xpZW50 ICZxdW90O2Jhc2ljJnF1b3Q7DQpyZXF1ZXN0IGNvbWVzIGluLCB0aGUgc2VydmVyIGFuc3dlcnMg aXQgd2l0aCBhICZxdW90O2Jhc2ljJnF1b3Q7IHJlc3BvbnNlDQooc28gZmFyLCBzbyBvYnZpb3Vz KSwgYnV0IGl0IGFkZGl0aW9uYWxseSBrZWVwcyBzdGF0ZSBmb3IgdGhpcyBhc3NvY2lhdGlvbi90 aGlzDQpzcGVjaWZpYyBleGNoYW5nZSg/KSwgaW4gY2FzZSB0aGF0IHRoZXJlIGlzIGV2ZXIgZ29p bmcgdG8gYmUgYW4gYWRkaXRpb25hbA0KY2xpZW50ICZxdW90O2ludGVybGVhdmUmcXVvdDsgcmVx dWVzdC4gQXMgbG9uZyBhcyB0aGUgc2VydmVyIHdpc2hlcyB0bw0Kb2ZmZXIgaW50ZXJsZWF2ZWQg bW9kZSwgdGhpcyBoYXBwZW5zIGFsd2F5cywgcmVnYXJkbGVzcyBvZiBuZWVkLjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhpcyBpcyBjb21wbGV0ZWx5IHJlYXNv bmFibGUgaWYgaXQNCmNhbiBiZSBleHBlY3RlZCB0aGF0IGV2ZXJ5ICZxdW90O2Jhc2ljJnF1b3Q7 IHJlcXVlc3QgKG9yIGF0IGxlYXN0IGEgdmVyeQ0KbGFyZ2UgcG9ydGlvbiBvZiB0aGVtKSB3aWxs IGV2ZW50dWFsbHkgYmUgZm9sbG93ZWQgdXAgdXBvbiB3aXRoIGFuICZxdW90O2ludGVybGVhdmUm cXVvdDsNCnJlcXVlc3QuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5JdCBkb2VzLCBob3dldmVyLCBzZWVtIGxpa2Ugc2VyaW91cw0Kb3ZlcmtpbGwgZm9yIGFueSBh c3NvY2lhdGlvbiB3aGVyZSBzdWNoIGEgZm9sbG93LXVwIGNhbGwgY2FuIG5vdCBiZSBleHBlY3Rl ZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgd291 bGQgdGhlcmVmb3JlIGFkdmlzZSBzb21lIGFkZGl0aW9uYWwNCmNvbW11bmljYXRpb24sIHRvIGdl dCByaWQgb2YgdGhlIGNhc2VzIHdoZXJlIHN0YXRlIGlzIGtlcHQgdW5uZWNlc3NhcmlseS48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIGNhbiBnbyBpbnRvIHNw ZWNpZmljcyBpZiB0aGVyZSBpcw0KaW50ZXJlc3QsIGJ1dCBJIHdhbnRlZCB0byBrZWVwIHRoaXMg ZGlzY3Vzc2lvbiBzdGFydGVyIHNob3J0LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+S3Jpc3RvZjwvZm9udD4NCg== --=_alternative 004F4C63C12581D7_=-- From nobody Mon Nov 13 06:56:14 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 4DE17128CD5 for ; Mon, 13 Nov 2017 06:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 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, 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 RL-l9Te2vHuG for ; Mon, 13 Nov 2017 06:56:11 -0800 (PST) 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 E88301293E3 for ; Mon, 13 Nov 2017 06:56:10 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8880EC014170; Mon, 13 Nov 2017 14:56:10 +0000 (UTC) Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A5767BCA5; Mon, 13 Nov 2017 14:56:08 +0000 (UTC) Date: Mon, 13 Nov 2017 15:56:07 +0100 From: Miroslav Lichvar To: kristof.teichel@ptb.de Cc: ntp@ietf.org, Aanchal Malhotra Message-ID: <20171113145607.GB20898@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 13 Nov 2017 14:56:10 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Draft on Interleave Mode -- Keeping "preemptive" per-client state 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, 13 Nov 2017 14:56:12 -0000 On Mon, Nov 13, 2017 at 03:26:07PM +0100, kristof.teichel@ptb.de wrote: > This is completely reasonable if it can be expected that every "basic" > request (or at least a very large portion of them) will eventually be > followed up upon with an "interleave" request. > It does, however, seem like serious overkill for any association where > such a follow-up call can not be expected. > > I would therefore advise some additional communication, to get rid of the > cases where state is kept unnecessarily. That is a good point. One option would be to check if the origin timestamp is not zero before saving/updating the state. Majority of public NTP traffic is from various SNTP clients, which send packets with zero origin timestamp. Full NTP clients using the basic mode and following the data minimization draft will do that too. In order to avoid delaying the first response in the interleaved mode by one client/server exchange, the clients could send the first request with a dummy (random?) origin timestamp. -- Miroslav Lichvar From nobody Mon Nov 13 09:33: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 1E3AE124BAC for ; Mon, 13 Nov 2017 09:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 GRMEySJByCeB for ; Mon, 13 Nov 2017 09:33:00 -0800 (PST) Received: from relay52.bu.edu (relay52.bu.edu [128.197.228.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89960127137 for ; Mon, 13 Nov 2017 09:32:58 -0800 (PST) X-Envelope-From: aanchal4@bu.edu Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) by relay52.bu.edu (8.14.3/8.14.3) with ESMTP id vADHWb0L024054 for ; Mon, 13 Nov 2017 12:32:38 -0500 Received: by mail-lf0-f72.google.com with SMTP id n69so4402789lfn.18 for ; Mon, 13 Nov 2017 09:32:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZkSgkxvFXDLzN3zKqwFua3XNmlNF9Vilg57NK4VODCw=; b=Al++F/T78tW9PVIj0BpMB5bRe0GJTPRjtRQi5fztRKqm5ZY544f6SNflfW2lg8p/O8 rnOa8tgwxpa7vLBUftrp5dESR9tLF8NY6mP/utxqlWH7OzYFnEKtpAKLD+cMk6FyBQQb xKLqwdQIwBVowmd+ZQcXnSQGMnTBSWyOmQeI3FAibkLafWfg3hMCFoQVWMs7dVPelj82 KepVzGPwW0EJDSCHDRIoeoz9esh3x+wXKhGRiH2SYlSvVdCnYxYs89XDe5bkrC6mD3oD /wUszbquYPWVsLJYWp+Bd+jsg4zqk4brlmzYRVx5pP1wXEDVE0nkNEmSA/W+IwTHU7yp r8OA== X-Gm-Message-State: AJaThX772bUq50sh5jQ9J3DffjDZU5rJwjAJARPIDGU/sEAeI7Y/OBJv cmTMF7UszLzmXdElZir+5y4g8zrYMNUAo7Ioxu05/JXREiW5O8EDhK+DwV4Wx7rFARv0dcz5opB qWUnXoqUbYq899kFGUwKA X-Received: by 10.46.22.83 with SMTP id 19mr3497317ljw.147.1510594357442; Mon, 13 Nov 2017 09:32:37 -0800 (PST) X-Google-Smtp-Source: AGs4zMY4gi244UMeBI78BcAqyzOEcFu53TbTZ4U8hriMvUOn/IFF6BQJMhGgEC3GfExuV0Xj4aUJ4bbmAT/7aNicKsU= X-Received: by 10.46.22.83 with SMTP id 19mr3497308ljw.147.1510594357138; Mon, 13 Nov 2017 09:32:37 -0800 (PST) MIME-Version: 1.0 References: <20171113145607.GB20898@localhost> In-Reply-To: <20171113145607.GB20898@localhost> From: Aanchal Malhotra Date: Mon, 13 Nov 2017 17:32:26 +0000 Message-ID: To: Miroslav Lichvar Cc: kristof.teichel@ptb.de, ntp@ietf.org Content-Type: multipart/alternative; boundary="f403045fc03e0eaaed055de0a84a" Archived-At: Subject: Re: [Ntp] Draft on Interleave Mode -- Keeping "preemptive" per-client state 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, 13 Nov 2017 17:33:03 -0000 --f403045fc03e0eaaed055de0a84a Content-Type: text/plain; charset="UTF-8" As far as I understand, kristoff is trying to say is the following: 1) we should be able to get rid of the preemptively stored "state" on the server supporting interleaved mode for each client. 2) Look for options where a client can tell in its basic mode request, somehow, if he wants the next response to be in the interleaved mode, thus indicating to the server that it should now start to save the state for this client to be able to respond in the interleaved mode in the next response. Correct me if I am wrong Kristof? Solution: If we are really conservative about saving even a little additional information for each client on the server preemptively, we could have a couple of choices here: 1) as Miroslav mentioned, the origin time stamp on the client basic mode request can be random, thus indicating to the server that the next request from this client is going to be an interleaved request and so the server should start saving the state for this client. 2) have something (a bit) in the extensions field of the client basic mode request packet that indicates to the server that the next request from the client is going to be in the interleaved mode and that it should start saving the state for this client. Miroslav and I had a discussion on having a separate mode number for interleaved mode but since there is just 3 bits for the mode field in the NTP packet, that does not seem like a feasible option. In short, my point is that what Kristof is concerned about is the "state" that the server has to keep preemptively for each of its client! Thx! Aanchal. On Mon, Nov 13, 2017 at 10:56 PM Miroslav Lichvar wrote: > On Mon, Nov 13, 2017 at 03:26:07PM +0100, kristof.teichel@ptb.de wrote: > > This is completely reasonable if it can be expected that every "basic" > > request (or at least a very large portion of them) will eventually be > > followed up upon with an "interleave" request. > > It does, however, seem like serious overkill for any association where > > such a follow-up call can not be expected. > > > > I would therefore advise some additional communication, to get rid of the > > cases where state is kept unnecessarily. > > That is a good point. > > One option would be to check if the origin timestamp is not zero > before saving/updating the state. Majority of public NTP traffic is > from various SNTP clients, which send packets with zero origin > timestamp. Full NTP clients using the basic mode and following the > data minimization draft will do that too. > > In order to avoid delaying the first response in the interleaved mode > by one client/server exchange, the clients could send the first > request with a dummy (random?) origin timestamp. > > -- > Miroslav Lichvar > -- Sent from iPhone --f403045fc03e0eaaed055de0a84a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As far as I understand, kristoff is trying to say is= the following:
1) we should be able to get rid of t= he preemptively stored "state" on the server supporting interleav= ed mode for each client.=C2=A0

2) Look for options where a client can tell in its basic mode reques= t, somehow, if he wants the next response to be in the interleaved mode, th= us indicating to the server that it should now start to save the state for = this client to be able to respond in the interleaved mode in the next respo= nse.=C2=A0

Correct me if= I am wrong Kristof?

Sol= ution: If we are really conservative about saving even a little additional = information for each client on the server preemptively, we could have a cou= ple of choices here:

1) = as Miroslav mentioned, the origin time stamp on the client basic mode reque= st can be random, thus indicating to the server that the next request from = this client is going to be an interleaved request and so the server should = start saving the state for this client.

2) have something (a bit) in the extensions field of the cl= ient basic mode request packet that indicates to the server that the next r= equest from the client is going to be in the interleaved mode and that it s= hould start saving the state for this client.

Miroslav and I had a discussion on having a separate = mode number for interleaved mode but since there is just 3 bits for the mod= e field in the NTP packet, that does not seem like a feasible option.
=

In short, my point is that wh= at Kristof is concerned about is the "state" that the server has = to keep preemptively for each of its client!=C2=A0
<= br>
Thx!=C2=A0
Aanchal.
=
On Mon, Nov 13, 2017 at 10:56 PM Mirosl= av Lichvar <mlichvar@redhat.com> wrote:
On Mon, Nov 13, 2017 = at 03:26:07PM +0100, kristof.teichel@ptb.de wrote:
> This is completely reasonable if it can be expected that every "b= asic"
> request (or at least a very large portion of them) will eventually be<= br> > followed up upon with an "interleave" request.
> It does, however, seem like serious overkill for any association where=
> such a follow-up call can not be expected.
>
> I would therefore advise some additional communication, to get rid of = the
> cases where state is kept unnecessarily.

That is a good point.

One option would be to check if the origin timestamp is not zero
before saving/updating the state. Majority of public NTP traffic is
from various SNTP clients, which send packets with zero origin
timestamp. Full NTP clients using the basic mode and following the
data minimization draft will do that too.

In order to avoid delaying the first response in the interleaved mode
by one client/server exchange, the clients could send the first
request with a dummy (random?) origin timestamp.

--
Miroslav Lichvar
--
Sent from iPhone
--f403045fc03e0eaaed055de0a84a-- From nobody Tue Nov 14 00: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 976CA128D16 for ; Tue, 14 Nov 2017 00:05:10 -0800 (PST) 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 kR1qwP3B-mmO for ; Tue, 14 Nov 2017 00:05:07 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.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 8CA6F124234 for ; Tue, 14 Nov 2017 00:05:06 -0800 (PST) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vAE844QO011756-vAE844QQ011756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Nov 2017 09:04:04 +0100 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id D8DC95AAADC for ; Tue, 14 Nov 2017 09:04:04 +0100 (CET) In-Reply-To: References: To: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Tue, 14 Nov 2017 09:04:02 +0100 Content-Type: multipart/alternative; boundary="=_alternative 002C517FC12581D8_=" Archived-At: Subject: Re: [Ntp] Draft on Interleave Mode -- Keeping "preemptive" per-client state 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, 14 Nov 2017 08:05:10 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002C517FC12581D8_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQp3aGVuIEkgd3JvdGUgbXkgbGFzdCBtYWlsIChjaXRlZCBiZWxvdyksIEkg aGFkIGFscmVhZHkgZmxlc2hlZCBvdXQgc29tZSANCmRldGFpbGVkIHRleHQsIGJ1dCBJIGRpZCBu b3Qgd2FudCB0byBpbmNsdWRlIGl0IHlldCwgYmVjYXVzZSB0aGF0IHdvdWxkIA0KaGF2ZSBtYWRl IGZvciBhbiBvdmVyYWxsIHF1aXRlIGxhcmdlIHdhbGwtb2YtdGV4dC4NCkknbSBzdWJtaXR0aW5n IGl0IG5vdywgc2luY2UgdGhlcmUgYXBwZWFycyB0byBiZSBpbnRlcmVzdCBpbiB0aGUgdG9waWMu IA0KVGhpcyBpcyBqdXN0IG15IG1vcmUgZGV0YWlsZWQgaW5wdXQsIGl0IGlzIG5vdCB5ZXQgdG8g YmUgdW5kZXJzdG9vZCBhcyBhIA0KcmVzcG9uc2UgdG8gTWlyb3NsYXYgb3IgQWFuY2hhbC4gSSB3 aWxsIGdldCB0byB0aGF0IGxhdGVyIHRvZGF5Lg0KDQoNCkRldGFpbHM6DQoNCkluIHRoZSB3b3Jr aW5nIGdyb3VwIHNlc3Npb24gdGhpcyBhZnRlcm5vb24gaW4gU2luZ2Fwb3JlLCBBYW5jaGFsIGhp bnRlZCANCnRoYXQgdGhlIHJlYXNvbmluZyBmb3ByIHRoaXMgZGVjaXNpb24gaGFzIHRvIGRvIHdp dGggc3RhdGUgdGhhdCB3b3VsZCBiZSANCmtlcHQgYW55d2F5IChmb3IgdHJhZmZpYyBsaW1pdGFp b25zLCBhcyBmYXIgYXMgSSB1bmRlcnN0b29kKS4gSSB3b3VsZCBsaWtlIA0KdG8gcG9pbnQgb3V0 IHRoYXQNCg0KQSkgSSBkb24ndCBiZWxpZXZlIGl0IHRvIGJlIGEgaGVhbHRoeSBhc3N1bXB0aW9u IHRoYXQgdGhpcyBoYXBwZW5zIA0KImFueXdheSIuDQpJbiBwcmluY2lwbGUsIHRyYWZmaWMgbGlt aXRhdGlvbiBkbyBub3QgbmVjZXNzYXJpbHkgaGF2ZSB0byBiZSBkb25lIGF0IHRoZSANCnNhbWUg cGxhY2Ugd2hlcmUgTlRQIHJlc3BvbnNlcyBhcmUgZ2VuZXJhdGVkLiBBbHNvLCB0cmFmZmljIGxp bWl0YXRpb25zIGRvIA0Kbm90IG5lY2Vzc2FyaWx5IGhhdmUgdG8gYmUgZG9uZSBvbiBhIHBlci1j bGllbnQgYmFzaXMuDQpPdmVyYWxsLCBJJ20gc2F5aW5nIHRoYXQgaW4gdGhlIGludGVyZXN0IG9m IGEgcG90ZW50aWFsbHkgbW9kdWxhciBhcHByb2FjaCANCnRvIGltcGxlbWVudGluZyBhbGwgdGhl IGRpZmZlcmVudCBzcGVjaWZpY2F0aW9ucyB0aGF0IGFyZSBiZWluZyB3cml0dGVuIA0KY3VycmVu dGx5LCBJIGRvbid0IGxpa2UgdG8gaGF2ZSB1bm5lY2Vzc2FyeSBhc3N1bXB0aW9ucyBhYm91dCBh IG1vZHVsZSBYIA0KaW4gdGhlIGRlc2lnbiBmb3IgbW9kdWxlIFkuV2hpY2ggYnJpbmdzIG1lIHRv IG15IG5leHQgcG9pbnQ6DQoNCkIpIEkgZG9uJ3Qgc2VlIGhvdyBpdCBpcyBpbiBhbnl3YXkgbmVj ZXNzYXJ5IChvciBldmVuIHNpZ25pZmljYW50bHkgDQpiZW5lZmljaWFsKSB0byBkbyBpdCB0aGlz IHdheS4NClNwZWNpZmljYWxseSwgSSBkb24ndCBzZWUgaG93IGl0IGlzIGJldHRlciB0aGFuIGVp dGhlciBvZiB0aGUgZm9sbG93aW5nIA0KYWx0ZXJuYXRpdmVzOg0KICAtIFJFU1RSSUNUIHRoZSBi ZWhhdmlvciBhYm92ZSAoa2VlcGluZyBzdGF0ZSkgdG8gaGFwcGVuIG9ubHkgaWYgdGhlIA0KZmly c3QgKCJiYXNpYyIpIHJlcXVlc3QgaGFzIHNvbWUga2luZCBvZiBzaWduYWxsaW5nIGZsYWcgaW4g aXQuDQogIC0gUkVQTEFDRSB0aGUgImludGVybGVhdmUiIHJlcXVlc3Qgb24gdGhlIGNsaWVudCBz aWRlIHdpdGggYSBzaWduYWxsaW5nIA0KZmxhZyBpbiB0aGUgImJhc2ljIiByZXF1ZXN0LiBTZW1h bnRpY2FsbHksIHRoaXMgd291bGQgYmFzaWNhbGx5IHNheSAic2VuZCANCm1lIGFuIGFkZGl0aW9u YWwgJ2ludGVybGVhdmUnIHJlc3BvbnNlIGFzIHNvb24gYXMgcG9zc2libGUiLg0KQm90aCBvZiB0 aGVzZSBzZWVtIHRvIGNhdXNlIHZlcnkgbGl0dGxlIGFkZGl0aW9uYWwgY29zdCB0aGVtc2VsdmVz IChhIGZldyANCm1vcmUgYml0cyBpbiB0aGUgY29tbXVuaWNhdGlvbiwgYSBiaXQgbW9yZSBwcm9j ZXNzaW5nKSwgYW5kIHdvdWxkIGN1dCAxMDAlIA0Kb2YgdGhlIGFkZGl0aW9uYWwgY29zdHMgaW4g dGhlIHVubmVjZXNzYXJ5IGNhc2VzIGRlc2NyaWJlZCBhYm92ZSAod2hlcmUgDQpjbGllbnRzIGRv IG5vdCBpbnRlbmQgdG8gZm9sbG93IHVwIHdpdGggImludGVybGVhdmUiIHJlcXVlc3RzKS4NCg0K DQpCZXN0IHJlZ2FyZHMsDQpLcmlzdG9mDQoNCg0KDQpWb246ICAgIGtyaXN0b2YudGVpY2hlbEBw dGIuZGUNCkFuOiAgICAgbnRwQGlldGYub3JnDQpLb3BpZTogIEFhbmNoYWwgTWFsaG90cmEgPGFh bmNoYWw0QGJ1LmVkdT4NCkRhdHVtOiAgMTMuMTEuMjAxNyAxNToyNw0KQmV0cmVmZjogICAgICAg IFtOdHBdIERyYWZ0IG9uIEludGVybGVhdmUgTW9kZSAtLSBLZWVwaW5nICJwcmVlbXB0aXZlIiAN CnBlci1jbGllbnQgc3RhdGUNCkdlc2VuZGV0IHZvbjogICAibnRwIiA8bnRwLWJvdW5jZXNAaWV0 Zi5vcmc+DQoNCg0KDQrigItIZWxsbyBhbGwsIA0KDQpJIHdhbnRlZCB0byBzdGFydC9yZXZpdmUg YSBkaXNjdXNzaW9uIGFib3V0IHRoZSBpbnRlcmxlYXZlIG1vZGUgZGVzY3JpYmVkIA0KaW4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9wZGYvZHJhZnQtbWxpY2h2YXItbnRwLWludGVybGVhdmVkLW1v ZGVzLTAwLnBkZi4gDQoNCg0KQ3VycmVudGx5LCB0aGUgYmVoYXZpb3JhbCBzY2hlbWUgZm9yIGEg c2VydmVyIHNlZW1zIHRvIGJlIHJvdWdobHkgdGhlIA0KZm9sbG93aW5nOiANCldoZW5ldmVyIGEg Y2xpZW50ICJiYXNpYyIgcmVxdWVzdCBjb21lcyBpbiwgdGhlIHNlcnZlciBhbnN3ZXJzIGl0IHdp dGggYSANCiJiYXNpYyIgcmVzcG9uc2UgKHNvIGZhciwgc28gb2J2aW91cyksIGJ1dCBpdCBhZGRp dGlvbmFsbHkga2VlcHMgc3RhdGUgZm9yIA0KdGhpcyBhc3NvY2lhdGlvbi90aGlzIHNwZWNpZmlj IGV4Y2hhbmdlKD8pLCBpbiBjYXNlIHRoYXQgdGhlcmUgaXMgZXZlciANCmdvaW5nIHRvIGJlIGFu IGFkZGl0aW9uYWwgY2xpZW50ICJpbnRlcmxlYXZlIiByZXF1ZXN0LiBBcyBsb25nIGFzIHRoZSAN CnNlcnZlciB3aXNoZXMgdG8gb2ZmZXIgaW50ZXJsZWF2ZWQgbW9kZSwgdGhpcyBoYXBwZW5zIGFs d2F5cywgcmVnYXJkbGVzcyANCm9mIG5lZWQuIA0KVGhpcyBpcyBjb21wbGV0ZWx5IHJlYXNvbmFi bGUgaWYgaXQgY2FuIGJlIGV4cGVjdGVkIHRoYXQgZXZlcnkgImJhc2ljIiANCnJlcXVlc3QgKG9y IGF0IGxlYXN0IGEgdmVyeSBsYXJnZSBwb3J0aW9uIG9mIHRoZW0pIHdpbGwgZXZlbnR1YWxseSBi ZSANCmZvbGxvd2VkIHVwIHVwb24gd2l0aCBhbiAiaW50ZXJsZWF2ZSIgcmVxdWVzdC4gDQpJdCBk b2VzLCBob3dldmVyLCBzZWVtIGxpa2Ugc2VyaW91cyBvdmVya2lsbCBmb3IgYW55IGFzc29jaWF0 aW9uIHdoZXJlIA0Kc3VjaCBhIGZvbGxvdy11cCBjYWxsIGNhbiBub3QgYmUgZXhwZWN0ZWQuIA0K DQpJIHdvdWxkIHRoZXJlZm9yZSBhZHZpc2Ugc29tZSBhZGRpdGlvbmFsIGNvbW11bmljYXRpb24s IHRvIGdldCByaWQgb2YgdGhlIA0KY2FzZXMgd2hlcmUgc3RhdGUgaXMga2VwdCB1bm5lY2Vzc2Fy aWx5LiANCldlIGNhbiBnbyBpbnRvIHNwZWNpZmljcyBpZiB0aGVyZSBpcyBpbnRlcmVzdCwgYnV0 IEkgd2FudGVkIHRvIGtlZXAgdGhpcyANCmRpc2N1c3Npb24gc3RhcnRlciBzaG9ydC4gDQoNCg0K QmVzdCByZWdhcmRzLCANCktyaXN0b2YgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm50cCBtYWlsaW5nIGxpc3QNCm50cEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHANCg0KDQoNCg== --=_alternative 002C517FC12581D8_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvIGFsbCw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPndoZW4gSSB3cm90ZSBteSBsYXN0IG1h aWwgKGNpdGVkIGJlbG93KSwNCkkgaGFkIGFscmVhZHkgZmxlc2hlZCBvdXQgc29tZSBkZXRhaWxl ZCB0ZXh0LCBidXQgSSBkaWQgbm90IHdhbnQgdG8gaW5jbHVkZQ0KaXQgeWV0LCBiZWNhdXNlIHRo YXQgd291bGQgaGF2ZSBtYWRlIGZvciBhbiBvdmVyYWxsIHF1aXRlIGxhcmdlIHdhbGwtb2YtdGV4 dC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknbSBzdWJtaXR0 aW5nIGl0IG5vdywgc2luY2UgdGhlcmUgYXBwZWFycw0KdG8gYmUgaW50ZXJlc3QgaW4gdGhlIHRv cGljLiBUaGlzIGlzIGp1c3QgbXkgbW9yZSBkZXRhaWxlZCBpbnB1dCwgaXQgaXMNCm5vdCB5ZXQg dG8gYmUgdW5kZXJzdG9vZCBhcyBhIHJlc3BvbnNlIHRvIE1pcm9zbGF2IG9yIEFhbmNoYWwuIEkg d2lsbCBnZXQNCnRvIHRoYXQgbGF0ZXIgdG9kYXkuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5EZXRhaWxzOjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW4gdGhlIHdvcmtpbmcgZ3JvdXAgc2Vzc2lv biB0aGlzIGFmdGVybm9vbg0KaW4gU2luZ2Fwb3JlLCBBYW5jaGFsIGhpbnRlZCB0aGF0IHRoZSBy ZWFzb25pbmcgZm9wciB0aGlzIGRlY2lzaW9uIGhhcw0KdG8gZG8gd2l0aCBzdGF0ZSB0aGF0IHdv dWxkIGJlIGtlcHQgYW55d2F5IChmb3IgdHJhZmZpYyBsaW1pdGFpb25zLCBhcw0KZmFyIGFzIEkg dW5kZXJzdG9vZCkuIEkgd291bGQgbGlrZSB0byBwb2ludCBvdXQgdGhhdDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QSkgSSBkb24ndCBiZWxpZXZlIGl0 IHRvIGJlIGEgaGVhbHRoeQ0KYXNzdW1wdGlvbiB0aGF0IHRoaXMgaGFwcGVucyAmcXVvdDthbnl3 YXkmcXVvdDsuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbiBw cmluY2lwbGUsIHRyYWZmaWMgbGltaXRhdGlvbiBkbw0Kbm90IG5lY2Vzc2FyaWx5IGhhdmUgdG8g YmUgZG9uZSBhdCB0aGUgc2FtZSBwbGFjZSB3aGVyZSBOVFAgcmVzcG9uc2VzIGFyZQ0KZ2VuZXJh dGVkLiBBbHNvLCB0cmFmZmljIGxpbWl0YXRpb25zIGRvIG5vdCBuZWNlc3NhcmlseSBoYXZlIHRv IGJlIGRvbmUNCm9uIGEgcGVyLWNsaWVudCBiYXNpcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPk92ZXJhbGwsIEknbSBzYXlpbmcgdGhhdCBpbiB0aGUgaW50ZXJl c3QNCm9mIGEgcG90ZW50aWFsbHkgbW9kdWxhciBhcHByb2FjaCB0byBpbXBsZW1lbnRpbmcgYWxs IHRoZSBkaWZmZXJlbnQgc3BlY2lmaWNhdGlvbnMNCnRoYXQgYXJlIGJlaW5nIHdyaXR0ZW4gY3Vy cmVudGx5LCBJIGRvbid0IGxpa2UgdG8gaGF2ZSB1bm5lY2Vzc2FyeSBhc3N1bXB0aW9ucw0KYWJv dXQgYSBtb2R1bGUgWCBpbiB0aGUgZGVzaWduIGZvciBtb2R1bGUgWS5XaGljaCBicmluZ3MgbWUg dG8gbXkgbmV4dA0KcG9pbnQ6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5CKSBJIGRvbid0IHNlZSBob3cgaXQgaXMgaW4gYW55d2F5IG5lY2Vzc2FyeQ0K KG9yIGV2ZW4gc2lnbmlmaWNhbnRseSBiZW5lZmljaWFsKSB0byBkbyBpdCB0aGlzIHdheS48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNwZWNpZmljYWxseSwgSSBk b24ndCBzZWUgaG93IGl0IGlzDQpiZXR0ZXIgdGhhbiBlaXRoZXIgb2YgdGhlIGZvbGxvd2luZyBh bHRlcm5hdGl2ZXM6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgLSBSRVNUUklDVCB0aGUgYmVoYXZpb3IgYWJvdmUNCihrZWVwaW5nIHN0YXRlKSB0byBo YXBwZW4gb25seSBpZiB0aGUgZmlyc3QgKCZxdW90O2Jhc2ljJnF1b3Q7KSByZXF1ZXN0DQpoYXMg c29tZSBraW5kIG9mIHNpZ25hbGxpbmcgZmxhZyBpbiBpdC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAtIFJFUExBQ0UgdGhlICZxdW90O2ludGVybGVh dmUmcXVvdDsNCnJlcXVlc3Qgb24gdGhlIGNsaWVudCBzaWRlIHdpdGggYSBzaWduYWxsaW5nIGZs YWcgaW4gdGhlICZxdW90O2Jhc2ljJnF1b3Q7DQpyZXF1ZXN0LiBTZW1hbnRpY2FsbHksIHRoaXMg d291bGQgYmFzaWNhbGx5IHNheSAmcXVvdDtzZW5kIG1lIGFuIGFkZGl0aW9uYWwNCidpbnRlcmxl YXZlJyByZXNwb25zZSBhcyBzb29uIGFzIHBvc3NpYmxlJnF1b3Q7LjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Qm90aCBvZiB0aGVzZSBzZWVtIHRvIGNhdXNlIHZl cnkgbGl0dGxlDQphZGRpdGlvbmFsIGNvc3QgdGhlbXNlbHZlcyAoYSBmZXcgbW9yZSBiaXRzIGlu IHRoZSBjb21tdW5pY2F0aW9uLCBhIGJpdA0KbW9yZSBwcm9jZXNzaW5nKSwgYW5kIHdvdWxkIGN1 dCAxMDAlIG9mIHRoZSBhZGRpdGlvbmFsIGNvc3RzIGluIHRoZSB1bm5lY2Vzc2FyeQ0KY2FzZXMg ZGVzY3JpYmVkIGFib3ZlICh3aGVyZSBjbGllbnRzIGRvIG5vdCBpbnRlbmQgdG8gZm9sbG93IHVw IHdpdGggJnF1b3Q7aW50ZXJsZWF2ZSZxdW90Ow0KcmVxdWVzdHMpLjwvZm9udD4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzLDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+S3Jpc3RvZjwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5z LXNlcmlmIj5Wb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmtyaXN0b2YudGVpY2hlbEBwdGIuZGU8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+QW46ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Pm50cEBpZXRmLm9yZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNl PSJzYW5zLXNlcmlmIj5Lb3BpZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+QWFuY2hhbCBNYWxob3RyYSAmbHQ7YWFuY2hh bDRAYnUuZWR1Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNl PSJzYW5zLXNlcmlmIj5EYXR1bTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MTMuMTEuMjAxNyAxNToyNzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5CZXRyZWZmOiAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5bTnRwXSBEcmFmdA0Kb24gSW50ZXJsZWF2ZSBNb2RlIC0tIEtlZXBpbmcgJnF1b3Q7 cHJlZW1wdGl2ZSZxdW90OyBwZXItY2xpZW50IHN0YXRlPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkdlc2VuZGV0IHZvbjogJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ JnF1b3Q7bnRwJnF1b3Q7DQombHQ7bnRwLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJy Pg0KPGhyIG5vc2hhZGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPuKAizwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SGVsbG8gYWxsLDwvZm9udD48Zm9udCBzaXpl PTM+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkkg d2FudGVkIHRvIHN0YXJ0L3Jldml2ZSBhIGRpc2N1c3Npb24gYWJvdXQgdGhlIGludGVybGVhdmUg bW9kZSBkZXNjcmliZWQNCmluIDwvZm9udD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L3BkZi9kcmFmdC1tbGljaHZhci1udHAtaW50ZXJsZWF2ZWQtbW9kZXMtMDAucGRmIj48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwczovL3Rvb2xzLmlldGYu b3JnL3BkZi9kcmFmdC1tbGljaHZhci1udHAtaW50ZXJsZWF2ZWQtbW9kZXMtMDAucGRmPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi48L2ZvbnQ+PGZvbnQgc2l6 ZT0zPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpD dXJyZW50bHksIHRoZSBiZWhhdmlvcmFsIHNjaGVtZSBmb3IgYSBzZXJ2ZXIgc2VlbXMgdG8gYmUg cm91Z2hseSB0aGUgZm9sbG93aW5nOjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCldoZW5ldmVyIGEgY2xpZW50ICZxdW90O2Jh c2ljJnF1b3Q7IHJlcXVlc3QgY29tZXMgaW4sIHRoZSBzZXJ2ZXIgYW5zd2Vycw0KaXQgd2l0aCBh ICZxdW90O2Jhc2ljJnF1b3Q7IHJlc3BvbnNlIChzbyBmYXIsIHNvIG9idmlvdXMpLCBidXQgaXQg YWRkaXRpb25hbGx5DQprZWVwcyBzdGF0ZSBmb3IgdGhpcyBhc3NvY2lhdGlvbi90aGlzIHNwZWNp ZmljIGV4Y2hhbmdlKD8pLCBpbiBjYXNlIHRoYXQNCnRoZXJlIGlzIGV2ZXIgZ29pbmcgdG8gYmUg YW4gYWRkaXRpb25hbCBjbGllbnQgJnF1b3Q7aW50ZXJsZWF2ZSZxdW90OyByZXF1ZXN0Lg0KQXMg bG9uZyBhcyB0aGUgc2VydmVyIHdpc2hlcyB0byBvZmZlciBpbnRlcmxlYXZlZCBtb2RlLCB0aGlz IGhhcHBlbnMgYWx3YXlzLA0KcmVnYXJkbGVzcyBvZiBuZWVkLjwvZm9udD48Zm9udCBzaXplPTM+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KVGhpcyBpcyBjb21w bGV0ZWx5IHJlYXNvbmFibGUgaWYgaXQgY2FuIGJlIGV4cGVjdGVkIHRoYXQgZXZlcnkgJnF1b3Q7 YmFzaWMmcXVvdDsNCnJlcXVlc3QgKG9yIGF0IGxlYXN0IGEgdmVyeSBsYXJnZSBwb3J0aW9uIG9m IHRoZW0pIHdpbGwgZXZlbnR1YWxseSBiZSBmb2xsb3dlZA0KdXAgdXBvbiB3aXRoIGFuICZxdW90 O2ludGVybGVhdmUmcXVvdDsgcmVxdWVzdC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkl0IGRvZXMsIGhvd2V2ZXIsIHNlZW0g bGlrZSBzZXJpb3VzIG92ZXJraWxsIGZvciBhbnkgYXNzb2NpYXRpb24gd2hlcmUNCnN1Y2ggYSBm b2xsb3ctdXAgY2FsbCBjYW4gbm90IGJlIGV4cGVjdGVkLjwvZm9udD48Zm9udCBzaXplPTM+IDxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSSB3b3VsZCB0 aGVyZWZvcmUgYWR2aXNlIHNvbWUgYWRkaXRpb25hbCBjb21tdW5pY2F0aW9uLCB0byBnZXQgcmlk IG9mIHRoZQ0KY2FzZXMgd2hlcmUgc3RhdGUgaXMga2VwdCB1bm5lY2Vzc2FyaWx5LjwvZm9udD48 Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K V2UgY2FuIGdvIGludG8gc3BlY2lmaWNzIGlmIHRoZXJlIGlzIGludGVyZXN0LCBidXQgSSB3YW50 ZWQgdG8ga2VlcCB0aGlzDQpkaXNjdXNzaW9uIHN0YXJ0ZXIgc2hvcnQuPC9mb250Pjxmb250IHNp emU9Mz4gPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQpCZXN0IHJlZ2FyZHMsPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpLcmlzdG9mPC9mb250Pjxmb250IHNpemU9Mz4gPC9m b250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpudHAgbWFpbGluZyBsaXN0PGJyPg0KbnRwQGlldGYub3JnPGJyPg0K PC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L250cD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbnRwPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+ DQo8YnI+DQo8YnI+DQo= --=_alternative 002C517FC12581D8_=-- From nobody Tue Nov 14 02:42: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 EC20D120713 for ; Tue, 14 Nov 2017 02:42:01 -0800 (PST) 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 kVu1hE6ZMdYn for ; Tue, 14 Nov 2017 02:42:00 -0800 (PST) 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 20EC9126CC4 for ; Tue, 14 Nov 2017 02:42:00 -0800 (PST) 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 C10823C3D; Tue, 14 Nov 2017 10:41:59 +0000 (UTC) Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1C64760CA1; Tue, 14 Nov 2017 10:41:58 +0000 (UTC) Date: Tue, 14 Nov 2017 11:41:57 +0100 From: Miroslav Lichvar To: kristof.teichel@ptb.de Cc: ntp@ietf.org Message-ID: <20171114104157.GB32039@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 14 Nov 2017 10:41:59 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Draft on Interleave Mode -- Keeping "preemptive" per-client state 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, 14 Nov 2017 10:42:02 -0000 On Tue, Nov 14, 2017 at 09:04:02AM +0100, kristof.teichel@ptb.de wrote: > In the working group session this afternoon in Singapore, Aanchal hinted > that the reasoning fopr this decision has to do with state that would be > kept anyway (for traffic limitaions, as far as I understood). I would like > to point out that > > A) I don't believe it to be a healthy assumption that this happens > "anyway". > In principle, traffic limitation do not necessarily have to be done at the > same place where NTP responses are generated. Also, traffic limitations do > not necessarily have to be done on a per-client basis. > Overall, I'm saying that in the interest of a potentially modular approach > to implementing all the different specifications that are being written > currently, I don't like to have unnecessary assumptions about a module X > in the design for module Y. I agree that the specification should allow the server to avoid saving state for clients that do not use the interleaved mode, if it can be easily without breaking compatibility, e.g. using a new extension field. A check of the origin or receive timestamp seems like a good candidate. However, I'm not sure how much of a difference this will really make. How would an implementation where "saving state" for all clients had a significant cost on performance look like? I think there are basically two options how the server mode can be implemented. One uses a hash table to map IP addresses to one or two pairs of receive and transmit timestamps. The other uses a hash table to map receive timestamps to transmit timestamps, where all clients are mixed together and it's not necessary to save any IP address. In both cases I'd expect that saving the receive timestamp in order to detect a request in the interleaved mode is cheap. At least in my tests I didn't see a significant impact on performance. The transmit timestamp is more expensive, but that can be delayed until the client sends an actual request in the interleaved mode (i.e. origin timestamp matches a saved receive timestamp). > Which brings me to my next point: > > B) I don't see how it is in anyway necessary (or even significantly > beneficial) to do it this way. > Specifically, I don't see how it is better than either of the following > alternatives: > - RESTRICT the behavior above (keeping state) to happen only if the > first ("basic") request has some kind of signalling flag in it. Please keep in mind that the draft is trying to specify a protocol which is compatible with existing implementations of the "interleaved" mode. The interleaved client/server mode is just a special case of the interleaved symmetric mode. If you take an old version of ntpd and use the xleave option, a peer with no association which behaves like a server in the client/server mode and follows the specification should be able to detect and respond in the interleaved mode. > - REPLACE the "interleave" request on the client side with a signalling > flag in the "basic" request. Semantically, this would basically say "send > me an additional 'interleave' response as soon as possible". Wouldn't this be something like the follow-up message in PTP? I think the biggest issue is that it would allow traffic amplification. The request could be made longer than response to make the traffic symmetric, but that would create an asymmetric network delay and ruin the accuracy. -- Miroslav Lichvar From nobody Tue Nov 14 21:44: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 5A4D31294D2; Tue, 14 Nov 2017 21:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqr6ls3nQMCJ; Tue, 14 Nov 2017 21:44:47 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 305EB1276AF; Tue, 14 Nov 2017 21:44:44 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id u10so11359149otc.12; Tue, 14 Nov 2017 21:44:44 -0800 (PST) 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; bh=cVOt/dSz0ijVVnAQA0UuExRhgX9nyWGO45waPPkiAy0=; b=s14SKqJ0F4L56O10kwWAVO61DFd0y4gS/1kPfVGW2yrBerwjcPHnUzReA5LbBRk2GL aVCSMWYnQTAI3JlPewHJBxCPVNwsy/56v1BYRsq+TXm/8WAonAxQsXy+hA2yJFkclpi+ PL50XdRMZCO1G1bvv06tD/eH9KgMS0WsCZ98yOrAz3y6WwYz+irQWlyceO5VHblCeWQC TZ4AmycCPo7zWh09NsvpvEtjL+EOa6rmizmBKAjo+azgnVeLsuxIK6m8LRM+mHtvQp/z ziDtykJ26vOmbnEhIm6LYammzWkO1kNtktBD+mUTiybCTLltCxzZbPAl3UwC2L5YUi6M Y9CA== 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; bh=cVOt/dSz0ijVVnAQA0UuExRhgX9nyWGO45waPPkiAy0=; b=OuG2uVsjryfuuzzLfogtB9Jningtsq+ofTNRjIfP+l7VZCwXVUlAzrAcPbdigCNGsU J6IcBmg3pSujz1EWLUyVGdg7/gfMxUf0K3eibKnKsnCQr83BZXjkwZdMNrlvthDraWij o40ZhPtDyhfmIfFJBi9uQ3w/Ujv8Zl2rACOaxMdgVplwaAkqXBKS+muzS/Zx9t9qaghP 9k9FgS6/LVO91j1Wb74nZGpgGv7z6/YnlHM/RdVbucsq7sttndh56KY69cn84d7EEubz zL7l88T0OcbMtm5EyGIZe+7naWp056bpe/gNFa7S2COPLl+2yOPGFjSgsGMXoenIj5oc v0bg== X-Gm-Message-State: AJaThX6/kFwfjRYQX6QCqkQOHYMXDr+6g9x9Tg497bEbrHOqRX40GILi F+80rMXMNeMMkU2lUG2gXmAeIVjAbIb6/LDYlhCc0A== X-Google-Smtp-Source: AGs4zMbVu3VCggu9ZQNL2IQU/4EecErMHZaWwedJFYWb27t45/q35AO8w38N2E/BxC7jEi0XsIBHxzHuG5wUAfBlRQg= X-Received: by 10.157.44.41 with SMTP id f38mr5675904otb.211.1510724683303; Tue, 14 Nov 2017 21:44:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.168.70.1 with HTTP; Tue, 14 Nov 2017 21:44:42 -0800 (PST) In-Reply-To: References: From: Tal Mizrahi Date: Wed, 15 Nov 2017 13:44:42 +0800 Message-ID: To: ntp@ietf.org, draft-aanchal-time-implementation-guidance@ietf.org Content-Type: multipart/alternative; boundary="94eb2c11e8881a10bd055dff0081" Archived-At: Subject: Re: [Ntp] [NTP] Draft "On Implementing Time" 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, 15 Nov 2017 05:44:50 -0000 --94eb2c11e8881a10bd055dff0081 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, A few more comments to the authors of "On Implementing Time". Thanks for taking the time to write this draft. It is quite an interesting topic, and very challenging to cover. I believe the draft needs quite a bit of work. The first step should be to clearly define the scope of the document =E2=80=93 this should be done very carefully, and preferably in the abstract. More detailed comments: =C2=B7 In some cases the text describes a certain implementation me= thod and implies that this is =E2=80=9Cthe way=E2=80=9D to do it. We will have = to be very careful to distinguish between =E2=80=9Cthe way it works=E2=80=9D / =E2=80= =9Cthe way it sometimes works=E2=80=9D / =E2=80=9Cthe way we suggest it should work=E2=80=9D. =C2=B7 Please clearly describe the target audience and the scope of= the draft. The text should be very careful and clear, preferably in the Abstract. After reading the drat, it feels like it applies to timekeeping in PCs using NTP (not sure which OSs). Specifically: o Is the draft applicable to software or to hardware implementations? o Is the draft applicable only to NTP or also to PTP and other protocols? o Does the draft describe functionality that is specific to the architecture of a PC, or is it relevant for other devices as well (phones, IoT devices, switches, routers, base stations, synchrophasors)? o Is the draft applicable to a specific operating system, or does the described functionality work exactly the same in all operating systems? o Is the draft applicable only to physical machines, or also to virtual machines? =C2=B7 The intended status should be Informational. =C2=B7 It seems necessary to discuss the following terms, and expla= in how they relate to the current content of the draft: o System time. o Real time clock (RTC). o Tick. =C2=B7 Does the term =E2=80=98real time=E2=80=99 in the document re= fer to the value of the Real Time Clock (RTC)? If it is, please explain it in the document. =C2=B7 Does the term =E2=80=98raw time=E2=80=99 refer to a specific= hardware timer in the CPU? Perhaps the Time Stamp Counter (TSC)? If that is the case, please explain in the draft. This notion of raw time is not necessarily implemented in other network devices such as switches/routers. =C2=B7 =E2=80=9Cthe rate of advance of time is slowed down or sped = up slightly until it approaches the reference time again=E2=80=9D =E2=80=93 that may be= true in some implementations, but certainly not in all of them. Please phrase the text more carefully. =C2=B7 More generally, the distinction between raw time, adjusted r= aw time and real time =E2=80=93 please explain in detail where this is impleme= nted =E2=80=93 in which CPU architectures, and in which OSs. It is certainly not applicable to all devices that use clocks, right? =C2=B7 Throughout the document - the term =E2=80=98drift=E2=80=99 s= hould be well defined and used correctly. I would recommend to use Mill=E2=80=99s definition [Mil= ls] of drift (the first derivative of the frequency). This is often confused with =E2=80=98skew=E2=80=99, which is the frequency difference between two clock= s (i.e., the first derivative of the offset). [Mills] Mills, David L. "Improved algorithms for synchronizing computer network clocks." IEEE/ACM Transactions on networking 3.3 (1995): 245-254. =C2=B7 Please note that the definition of =E2=80=98real time=E2=80= =99 in the literature (e.g., [Lamport]) is different than the way you used this term. I would recommend to adopt Lamport=E2=80=99s terminology, or at least to cite it. o =E2=80=9CReal Time. An assumed Newtonian time frame that is not directl= y observable. o Clock Time. The time that is observed on some clock.=E2=80=9D [Lamport] Lamport, Leslie, and P. Michael Melliar-Smith. "Synchronizing clocks in the presence of faults." Journal of the ACM (JACM) 32.1 (1985): 52-78. =C2=B7 The term =E2=80=98timestamp=E2=80=99 is most commonly used a= s a single word in the RFC series (rather than time stamp). =C2=B7 =E2=80=9CIn order to reference the same point across multipl= e systems, it needs to be stated in wall time.=E2=80=9D - The word =E2=80=98needs=E2=80=99 is too strong here. Indeed a timestamp oft= en represents the wall time, but not always (see TCP for example). =C2=B7 =E2=80=9CHowever, in a network environment, the uncertainty = introduced by differing transmission times is likely larger than that introduced by clock drift.=E2=80=9D - it is hard to understand this sentence without a context. It looks like you have a specific application in mind, but the application is not clear to the reader. I would suggest to present this sentence as an example, not as a general rule. =C2=B7 Sections 4 and Section 5 =E2=80=93 I strongly recommend to e= xplicitly specify which implementations these sections refer to. That would make these sections well-scoped. =C2=B7 Security considerations =E2=80=93 should be extended. Specif= ically, I would suggest to add something like: =E2=80=9CA system that uses a time distribution protocols may be affected by the security aspects of the time protocol. The security considerations of time protocols in general are discussed in [RFC7384].=E2=80=9D =C2=B7 Typos: o s/componsated/compensated/ o s/adjested/adjusted/ Cheers, Tal. On Mon, Nov 13, 2017 at 5:21 PM, wrote: > Hello all, > > I have just given a read to the "On Implementing Time" draft ( > https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-mode= s). > > There are a few issues that I'd like to raise. > > (1) Vocabulary (technical): use of the term "time" > - Description: I take issue with not explaining what the document means > when in uses the term "time", specifically "a time", when > properties like continuous, monotonic (separate issue, see below) are > assigned. In these cases, it is heavily implied the "a time" is supposed = to > be a function (because the cited properties are usually applied to > functions), but this is never stated, which I find problematic. For > example, I still need to figure out what the domain and co-domain of the > function are supposed to be. Naively I would assume that the co-domain is= a > subset (probably implementation specific) of "int" or "float". I would th= en > assume that the domain is... well, "actual" time. Which brings me to my > next issue with the used terminology: "time" becomes an overloaded term, = it > represents the abstract heuristic concept and then also some kind of > function from this concept to a machine-appropriate value set. > - Suggested remedy: edit the terminology to be consistent, > - Specific suggestions for the remedy (even if this is deemed > insufficient, I still strongly advocate trying to implement the remedy in > some other way): > -- "Time" remains as the abstract heuristic concept (and is not > explained in the document). > -- The kind of value that a machine can read and communicate (for > example a timestamp) could be called a "clocktime". The document should > state this somewhere. How exactly "clocktime" is realized (int, float, ..= .) > is implementation specific. The document might or might not go into that > detail. > -- The function that maps the current "time" to a "clocktime" is called > a "clock". The document should state this somewhere. > > (2) Vocabulary (more editorial, with some technical implications): use of > the term "continuous" > - Description: since the co-domain of a "clock" (current term in the > document is "time", see above) is necessarily a discrete set, the notion = of > "continuity" causes some problems, since the usual definitions don't easi= ly > apply (basically, the function always has "jumps" in it, due to the > discrete nature of the co-domain). > - Suggestion: clean up the terminology and make it consistent, OR just > dumb it down. > - Specific suggestion (clean-up): have "continuous" mean that the functio= n > does not exhibit jumps greater than the "resolution" of the co-domain. Us= e > epsilon-delta definition, but loosen it to epsilon greater than or equal = to > . Note that this might require quite a lot of thougfht to get > right. > - Specific suggestion (dumb-down): simply state that "continuous" shall > mean that the function "has no substantial jumps", or something along tho= se > lines. > > (3) Vocabulary (technical and editorial): use of the term "monotonic" > - Description: Although I acknowledge that in 2.1, the draft gives a(n > implicit) definition of what it refers to when it uses the term "monotoni= c" > (i.e. "continuous and strictly monotonically increasing"), I still do not > like it. The term monotonic has a specific meaning in mathematics (to be > either monotonically increasing or monotonically decreasing), and I simpl= y > find it confusing to overload the term with a meaning that, on the one > hand, adds a property (also means "continuous" now) and, on the other han= d, > removes one of the original options (cannot mean "monotonically decreasin= g" > anymore). Stating that this terminology is "sometimes" used really doesn'= t > help the issue, since I find it to be an obvious crutch notation. > - Suggested remedy: come up with another term X instead of monotonic and > replace the sentence > by , modulo any potential changes in > vocabulary for the term "time". > > If there is interest (if the current editors think it would make things > easier and not harder), I guess I would offer to work on the draft as an > additional editor. > In any case, I think it is great that this kind of foundational work is > being done, and I think it is worth investing quite a lot of time and > thought, since there seems to be a severe lack of foundational content on > issues.like these > > > Best regards, > Kristof > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp > > --94eb2c11e8881a10bd055dff0081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

= A few more comments to the authors of "On Implementing Time".


Thanks for taking the time to write this draft. It i= s quite an interesting topic, and very challenging to cover.

=C2=A0

I believe the draft needs quite a bit of work. The f= irst step should be to clearly define the scope of the document =E2=80=93 this s= hould be done very carefully, and preferably in the abstract.

=C2=A0

=C2=A0More detailed comments:

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In some cases the text describes a certain implementation method and implies=C2=A0 that this is = =E2=80=9Cthe way=E2=80=9D to do it. We will have to be very careful to distinguish between =E2=80=9Cthe way it works=E2=80= =9D / =E2=80=9Cthe way it sometimes works=E2=80=9D / =E2=80=9Cthe way we suggest it should work=E2=80= =9D.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please clearly describe the target audience and the scope of the draft. The text should be very careful= and clear, preferably in the Abstract. After reading the drat, it feels like it applies to timekeeping in PCs using NTP (not sure which OSs).
Specifically:

o=C2=A0=C2=A0 <= /span>Is the draft applicable to software or to hardware implementations?

o=C2=A0=C2=A0 <= /span>Is the draft applicable only to NTP or also to PTP and other protocols?

o=C2=A0=C2=A0 <= /span>Does the draft describe functionality that is specific to the architecture of a PC, or is it relevant for other devices as well (phones, = IoT devices, switches, routers, base stations, synchrophasors)?

o=C2=A0=C2=A0 <= /span>Is the draft applicable to a specific operating system, or does the described functionality work exactly the same in all operating systems?=

o=C2=A0=C2=A0 <= /span>Is the draft applicable only to physical machines, or also to virtual machines?

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The intended status should be Informational.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It seems necessary to discuss the following terms, and explain how they relate to the current con= tent of the draft:

o=C2=A0=C2=A0 <= /span>System time.

o=C2=A0=C2=A0 <= /span>Real time clock (RTC).

o=C2=A0=C2=A0 <= /span>Tick.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Does the term =E2=80=98real time=E2= =80=99 in the document refer to the value of the Real Time Clock (RTC)? If it is, please explain it in the document.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Does the term =E2=80=98raw time=E2= =80=99 refer to a specific hardware timer in the CPU? Perhaps the Time Stamp Count= er (TSC)? If that is the case, please explain in the draft. This notion of raw time is not necessarily implemented in other network devices such as switches/routers.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9Cthe rate of advance of time is slowed down or sped up slightly until it approaches the reference t= ime again=E2=80=9D =E2=80=93 that may be true in some implementations, but certainly not in al= l of them. Please phrase the text more carefully.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 More generally, the distinction between raw time, adjusted raw time and real time =E2=80=93 ple= ase explain in detail where this is implemented =E2=80=93 in which CPU architectures, a= nd in which OSs. It is certainly not applicable to all devices that use clocks, right?<= span>

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Throughout the document - the term =E2=80=98drift=E2=80=99 should be well defined and used correctly. I w= ould recommend to use Mill=E2=80=99s definition [Mills] of drift (the first derivative of the= frequency). This is often confused with =E2=80=98skew=E2=80=99, which is the frequency = difference between two clocks (i.e., the first derivative of the offset).
[Mills] Mills, David L. "Improved algorithms for synchronizing compute= r network clocks." IEEE/ACM Transactions on networking 3.3 (1995): 245-2= 54.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please note that the definition of =E2=80=98real time=E2=80=99 in the literature (e.g., [Lamport= ]) is different than the way you used this term. I would recommend to adopt Lamport=E2=80=99s te= rminology, or at least to cite it.

o=C2=A0=C2=A0 <= /span>=E2=80=9CReal Time. An assumed Newtonian time frame that is not direc= tly observable.

o=C2=A0=C2=A0 <= /span>Clock Time. The time that is observed on some clock.=E2=80=9D

[Lamport] Lamport, Leslie= , and P. Michael Melliar-Smith. "Synchronizing clocks in the presence of faults." Journal of the ACM (JACM) 32.1 (1985): 52-78.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The term =E2=80=98timestamp=E2=80=99= is most commonly used as a single word in the RFC series (rather than time stamp).<= span>

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CIn order to reference the same point across multiple systems, it needs to be stated in wall time.=E2= =80=9D -
The word =E2=80=98needs=E2=80=99 is too strong here. Indeed a timestamp oft= en represents the wall time, but not always (see TCP for example).

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CHowever, in a network environment, the uncertainty introduced by differing transmission times is likely larger than that introduced by clock drift.=E2=80=9D
- it is hard to understand this sentence without a context. It looks like y= ou have a specific application in mind, but the application is not clear to th= e reader. I would suggest to present this sentence as an example, not as a general rule.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sections 4 and Section 5 =E2=80=93 I strongly recommend to explicitly specify which implementations these sect= ions refer to. That would make these sections well-scoped.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Security considerations =E2=80=93 should be extended. Specifically, I would suggest to add something like: = =E2=80=9CA system that uses a time distribution protocols may be affected by the secur= ity aspects of the time protocol. The security considerations of time protocols= in general are discussed in=C2=A0 [RFC7384].=E2=80=9D

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Typos:

o=C2=A0=C2=A0 <= /span>s/componsated/compensated/

o=C2=A0=C2=A0 <= /span>s/adjested/adjusted/

=C2=A0

Cheers,

Tal.


On Mon, Nov 13, 2017 at 5:21 PM, <k= ristof.teichel@ptb.de> wrote:
Hello all,

I have just given a read to the &q= uot;On Implementing Time" draft (https://datatracker.ietf.org/<= wbr>doc/html/draft-mlichvar-ntp-interleaved-modes).
There are a few issues that I'= d like to raise.

(1) Vocabulary (technical): use of= the term "time"
- Description: I take issue with n= ot explaining what the document means when in uses the term "time", specifically "a <property> time", when properties like continuous, monotonic (separate issue, see below) are assigned. In these cases, it is heavily implied the "a time" is supposed to be a function (because the cited properties are usually applied to functions), but this is never stated, which I find problematic. For example, I still need to figure out what the domain and co-domain of the function are suppos= ed to be. Naively I would assume that the co-domain is a subset (probably implementation specific) of "int" or "float". I would then assume that the domain is... well, "actual" time. Which brings me to my next issue with the used terminology: "time" becomes an overloaded term, it represents the abstract heuristic concept and then also some kind of function from this concept to a machine-appropri= ate value set.
- Suggested remedy: edit the termi= nology to be consistent,
- Specific suggestions for the rem= edy (even if this is deemed insufficient, I still strongly advocate trying to implement the remedy in some other way):
=C2=A0 -- "Time" remains= as the abstract heuristic concept (and is not explained in the document).
=C2=A0 -- The kind of value that a= machine can read and communicate (for example a timestamp) could be called a "= clocktime". The document should state this somewhere. How exactly "clocktime" is realized (int, float, ...) is implementation specific. The document might or might not go into that detail.
=C2=A0 -- The function that maps t= he current "time" to a "clocktime" is called a "clock= ". The document should state this somewhere.

(2) Vocabulary (more editorial, wi= th some technical implications): use of the term "continuous"
- Description: since the co-domain= of a "clock" (current term in the document is "time", see above) is necessarily a discrete set, the notion of "continuity&qu= ot; causes some problems, since the usual definitions don't easily apply (b= asically, the function always has "jumps" in it, due to the discrete nature of the co-domain).
- Suggestion: clean up the termino= logy and make it consistent, OR just dumb it down.
- Specific suggestion (clean-up): = have "continuous" mean that the function does not exhibit jumps greate= r than the "resolution" of the co-domain. Use epsilon-delta definit= ion, but loosen it to epsilon greater than or equal to <resolution>. Note that this might require quite a lot of thougfht to get right.
- Specific suggestion (dumb-down):= simply state that "continuous" shall mean that the function "has no substantial jumps", or something along those lines.

(3) Vocabulary (technical and edit= orial): use of the term "monotonic"
- Description: Although I acknowle= dge that in 2.1, the draft gives a(n implicit) definition of what it refers to when it uses the term "monotonic" (i.e. "continuous and strictly monotonically increasing"), I still do not like it. The term monotonic has a specific meaning in mathematics (to be either monotonically increasing or monotonically decreasing), and I simply find it confusing to overload the term with a meaning that, on the one hand, adds a property (also means "continuous" now) and, on the other hand, removes one of the original options (cannot mean "monotonically decreasing&quo= t; anymore). Stating that this terminology is "sometimes" used reall= y doesn't help the issue, since I find it to be an obvious crutch notatio= n.
- Suggested remedy: come up with a= nother term X instead of monotonic and replace the sentence <Such a time is sometimes called a "monotonic time."> by <We call such a time a [X] time.">, modulo any potential changes in vocabulary for the term "time".

If there is interest (if the curre= nt editors think it would make things easier and not harder), I guess I would offer to work on the draft as an additional editor.
In any case, I think it is great t= hat this kind of foundational work is being done, and I think it is worth inves= ting quite a lot of time and thought, since there seems to be a severe lack of foundational content on issues.like these


Best regards,
Kristof
________________= _______________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp


--94eb2c11e8881a10bd055dff0081-- From nobody Thu Nov 16 00:58: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 D9F98128B27 for ; Thu, 16 Nov 2017 00:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 2t-Jj9tqSJuo for ; Thu, 16 Nov 2017 00:58:01 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 9443D12869B for ; Thu, 16 Nov 2017 00:58:01 -0800 (PST) Received: from [IPv6:2001:67c:370:128:588c:c39:bafb:888c] (unknown [IPv6:2001:67c:370:128:588c:c39:bafb:888c]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 263BE81F2 for ; Thu, 16 Nov 2017 09:57:58 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1510822679; bh=vuxWlAaiwYd8WNQE/lipv2VqDRdPeJtxGY0hvJxtX10=; h=Subject:To:References:From:Date:In-Reply-To; b=OBlLxuYybG4McTdS7KTUB5la/pjOiG3S6HuWm5OsFlStTKhOu5EGzz4hw3SwsT4nr W/uCfTFpablGTzru3oiCcmV7apfZFq8xsrIaWClrvLD8a6iSl9FULNG1P8oEhUbbz4 7GUbCLLzdjiN7LimeNeOnFHhZCHawhqz/j31yvik= To: ntp@ietf.org References: From: Willem Toorop Message-ID: <843bdf3d-5a1f-3c61-6bf5-977666fcb03c@nlnetlabs.nl> Date: Thu, 16 Nov 2017 16:57:56 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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] [NTP] Draft "On Implementing Time" 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, 16 Nov 2017 08:58:05 -0000 Op 15-11-17 om 13:44 schreef Tal Mizrahi: > Hi, > >   > > A few more comments to the authors of "On Implementing Time". > > > Thanks for taking the time to write this draft. It is quite an > interesting topic, and very challenging to cover. > >   > > I believe the draft needs quite a bit of work. The first step should be > to clearly define the scope of the document – this should be done very > carefully, and preferably in the abstract. Thank you Tal, Yes, during the working-group discussion it became already very clear that our current wording is way too generic. Maybe we should already be more clear about scope in the title. We'll try to come up with a better one. This draft came from our study on the impact of security weaknesses of NTP on DNS and DNSSEC. We observed that DNS resolver caches (bind, unbound, knot, powerdns) were vulnerable to the attacks, and we also noticed that this could be mitigated if cache implementation would have been done differently. Other improvement were also apparent (such as scheduling of I/O events). We assume that the patterns used in writing this software are not unique and that other software might have the same flaws. During our study it became also clear that we needed clear definitions to describe these matters adequately. So our intention with the document was to 1. provide advise to implementors of software that has to practice caching and scheduling and other timing related matters. 2. provide clear definitions to be able to convey this advice. (it is ironic these were confusing to the experts ;) We will work with the workgroup to come up with better definitions and also to reference the canonical literature when making statements; starting with your and Kristof's comments. Thanks for that. We will start incorporating them and come up with an adapted draft. Cheers, -- Willem > >   > >  More detailed comments: > > ·         In some cases the text describes a certain implementation > method and implies  that this is “the way” to do it. We will have to be > very careful to distinguish between “the way it works” / “the way it > sometimes works” / “the way we suggest it should work”. > > ·         Please clearly describe the target audience and the scope of > the draft. The text should be very careful and clear, preferably in the > Abstract. After reading the drat, it feels like it applies to > timekeeping in PCs using NTP (not sure which OSs). > Specifically: > > o   Is the draft applicable to software or to hardware implementations? > > o   Is the draft applicable only to NTP or also to PTP and other protocols? > > o   Does the draft describe functionality that is specific to the > architecture of a PC, or is it relevant for other devices as well > (phones, IoT devices, switches, routers, base stations, synchrophasors)? > > o   Is the draft applicable to a specific operating system, or does the > described functionality work exactly the same in all operating systems? > > o   Is the draft applicable only to physical machines, or also to > virtual machines? > > ·         The intended status should be Informational. > > ·         It seems necessary to discuss the following terms, and explain > how they relate to the current content of the draft: > > o   System time. > > o   Real time clock (RTC). > > o   Tick. > > ·         Does the term ‘real time’ in the document refer to the value > of the Real Time Clock (RTC)? If it is, please explain it in the document. > > ·         Does the term ‘raw time’ refer to a specific hardware timer in > the CPU? Perhaps the Time Stamp Counter (TSC)? If that is the case, > please explain in the draft. This notion of raw time is not necessarily > implemented in other network devices such as switches/routers. > > ·         “the rate of advance of time is slowed down or sped up > slightly until it approaches the reference time again” – that may be > true in some implementations, but certainly not in all of them. Please > phrase the text more carefully. > > ·         More generally, the distinction between raw time, adjusted raw > time and real time – please explain in detail where this is implemented > – in which CPU architectures, and in which OSs. It is certainly not > applicable to all devices that use clocks, right? > > ·         Throughout the document - the term ‘drift’ should be well > defined and used correctly. I would recommend to use Mill’s definition > [Mills] of drift (the first derivative of the frequency). This is often > confused with ‘skew’, which is the frequency difference between two > clocks (i.e., the first derivative of the offset). > [Mills] Mills, David L. "Improved algorithms for synchronizing computer > network clocks." IEEE/ACM Transactions on networking 3.3 (1995): 245-254. > > ·         Please note that the definition of ‘real time’ in the > literature (e.g., [Lamport]) is different than the way you used this > term. I would recommend to adopt Lamport’s terminology, or at least to > cite it. > > o   “Real Time. An assumed Newtonian time frame that is not directly > observable. > > o   Clock Time. The time that is observed on some clock.” > > [Lamport] Lamport, Leslie, and P. Michael Melliar-Smith. "Synchronizing > clocks in the presence of faults." Journal of the ACM (JACM) 32.1 > (1985): 52-78. > > ·         The term ‘timestamp’ is most commonly used as a single word in > the RFC series (rather than time stamp). > > ·         “In order to reference the same point across multiple systems, > it needs to be stated in wall time.” - > The word ‘needs’ is too strong here. Indeed a timestamp often represents > the wall time, but not always (see TCP for example). > > ·         “However, in a network environment, the uncertainty introduced > by differing transmission times is likely larger than that introduced by > clock drift.” > - it is hard to understand this sentence without a context. It looks > like you have a specific application in mind, but the application is not > clear to the reader. I would suggest to present this sentence as an > example, not as a general rule. > > ·         Sections 4 and Section 5 – I strongly recommend to explicitly > specify which implementations these sections refer to. That would make > these sections well-scoped. > > ·         Security considerations – should be extended. Specifically, I > would suggest to add something like: “A system that uses a time > distribution protocols may be affected by the security aspects of the > time protocol. The security considerations of time protocols in general > are discussed in  [RFC7384].” > > ·         Typos: > > o   s/componsated/compensated/ > > o   s/adjested/adjusted/ > >   > > Cheers, > > Tal. > > > On Mon, Nov 13, 2017 at 5:21 PM, > wrote: > > Hello all, > > I have just given a read to the "On Implementing Time" draft > (https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes > ). > > There are a few issues that I'd like to raise. > > (1) Vocabulary (technical): use of the term "time" > - Description: I take issue with not explaining what the document > means when in uses the term "time", specifically "a > time", when properties like continuous, monotonic (separate issue, > see below) are assigned. In these cases, it is heavily implied the > "a time" is supposed to be a function (because the cited properties > are usually applied to functions), but this is never stated, which I > find problematic. For example, I still need to figure out what the > domain and co-domain of the function are supposed to be. Naively I > would assume that the co-domain is a subset (probably implementation > specific) of "int" or "float". I would then assume that the domain > is... well, "actual" time. Which brings me to my next issue with the > used terminology: "time" becomes an overloaded term, it represents > the abstract heuristic concept and then also some kind of function > from this concept to a machine-appropriate value set. > - Suggested remedy: edit the terminology to be consistent, > - Specific suggestions for the remedy (even if this is deemed > insufficient, I still strongly advocate trying to implement the > remedy in some other way): >   -- "Time" remains as the abstract heuristic concept (and is not > explained in the document). >   -- The kind of value that a machine can read and communicate (for > example a timestamp) could be called a "clocktime". The document > should state this somewhere. How exactly "clocktime" is realized > (int, float, ...) is implementation specific. The document might or > might not go into that detail. >   -- The function that maps the current "time" to a "clocktime" is > called a "clock". The document should state this somewhere. > > (2) Vocabulary (more editorial, with some technical implications): > use of the term "continuous" > - Description: since the co-domain of a "clock" (current term in the > document is "time", see above) is necessarily a discrete set, the > notion of "continuity" causes some problems, since the usual > definitions don't easily apply (basically, the function always has > "jumps" in it, due to the discrete nature of the co-domain). > - Suggestion: clean up the terminology and make it consistent, OR > just dumb it down. > - Specific suggestion (clean-up): have "continuous" mean that the > function does not exhibit jumps greater than the "resolution" of the > co-domain. Use epsilon-delta definition, but loosen it to epsilon > greater than or equal to . Note that this might require > quite a lot of thougfht to get right. > - Specific suggestion (dumb-down): simply state that "continuous" > shall mean that the function "has no substantial jumps", or > something along those lines. > > (3) Vocabulary (technical and editorial): use of the term "monotonic" > - Description: Although I acknowledge that in 2.1, the draft gives > a(n implicit) definition of what it refers to when it uses the term > "monotonic" (i.e. "continuous and strictly monotonically > increasing"), I still do not like it. The term monotonic has a > specific meaning in mathematics (to be either monotonically > increasing or monotonically decreasing), and I simply find it > confusing to overload the term with a meaning that, on the one hand, > adds a property (also means "continuous" now) and, on the other > hand, removes one of the original options (cannot mean > "monotonically decreasing" anymore). Stating that this terminology > is "sometimes" used really doesn't help the issue, since I find it > to be an obvious crutch notation. > - Suggested remedy: come up with another term X instead of monotonic > and replace the sentence "monotonic time."> by , modulo any > potential changes in vocabulary for the term "time". > > If there is interest (if the current editors think it would make > things easier and not harder), I guess I would offer to work on the > draft as an additional editor. > In any case, I think it is great that this kind of foundational work > is being done, and I think it is worth investing quite a lot of time > and thought, since there seems to be a severe lack of foundational > content on issues.like these > > > Best regards, > Kristof > _______________________________________________ > 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 > From nobody Thu Nov 16 01:21:10 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 9309C126C2F for ; Thu, 16 Nov 2017 01:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 CAJ7C1O3ZH1V for ; Thu, 16 Nov 2017 01:21:06 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 CC1F01200CF for ; Thu, 16 Nov 2017 01:21:05 -0800 (PST) Received: from grisu.home.partim.org (unknown [IPv6:2001:67c:370:128:911f:d883:da18:576c]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 3111C827D; Thu, 16 Nov 2017 10:21:03 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=opennetlabs.com Date: Thu, 16 Nov 2017 10:20:57 +0100 From: Martin Hoffmann To: kristof.teichel@ptb.de Cc: ntp@ietf.org Message-ID: <20171116102057.5a7c2df0@grisu.home.partim.org> In-Reply-To: References: Organization: Open Netlabs X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ntp] [NTP] Draft "On Implementing Time" 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, 16 Nov 2017 09:21:09 -0000 Hi Kristof, kristof.teichel@ptb.de wrote: >=20 > I have just given a read to the "On Implementing Time" draft ( > https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes > ).=20 > There are a few issues that I'd like to raise. Many thanks for reading the document and sharing your thoughts! > (1) Vocabulary (technical): use of the term "time" > - Description: I take issue with not explaining what the document > means when in uses the term "time", specifically "a time", > when properties like continuous, monotonic (separate issue, see > below) are assigned. In these cases, it is heavily implied the "a > time" is supposed to be a function (because the cited properties are > usually applied to functions), but this is never stated, which I find > problematic. For example, I still need to figure out what the domain > and co-domain of the function are supposed to be. Naively I would > assume that the co-domain is a subset (probably implementation > specific) of "int" or "float". I would then assume that the domain > is... well, "actual" time. Which brings me to my next issue with the > used terminology: "time" becomes an overloaded term, it represents > the abstract heuristic concept and then also some kind of function > from this concept to a machine-appropriate value set. > - Suggested remedy: edit the terminology to be consistent, > - Specific suggestions for the remedy (even if this is deemed=20 > insufficient, I still strongly advocate trying to implement the > remedy in some other way): > -- "Time" remains as the abstract heuristic concept (and is not=20 > explained in the document). > -- The kind of value that a machine can read and communicate (for=20 > example a timestamp) could be called a "clocktime". The document > should state this somewhere. How exactly "clocktime" is realized > (int, float, ...) is implementation specific. The document might or > might not go into that detail. > -- The function that maps the current "time" to a "clocktime" is > called a "clock". The document should state this somewhere. The draft already somewhat distinguishes between the two "classes" of definitions--wall time on the one side and the three remaining ones on the other, even if it doesn=E2=80=99t call out that distinction. I think we= can make this more obvious by simply using the word "clock" instead of "time" for the three concrete representations of time available to a system. We=E2=80=99ve been debating to what extent we should discuss the, for lack = of a better term, philosophical background of time, keeping in mind our target audience. On the one hand, this is all very important and interesting, on the other hand, we don=E2=80=99t want to scare away people starting out with a lengthy treatise.=20 > (2) Vocabulary (more editorial, with some technical implications): > use of the term "continuous" > - Description: since the co-domain of a "clock" (current term in the=20 > document is "time", see above) is necessarily a discrete set, the > notion of "continuity" causes some problems, since the usual > definitions don't easily apply (basically, the function always has > "jumps" in it, due to the discrete nature of the co-domain). > - Suggestion: clean up the terminology and make it consistent, OR > just dumb it down. > - Specific suggestion (clean-up): have "continuous" mean that the > function does not exhibit jumps greater than the "resolution" of the > co-domain. Use epsilon-delta definition, but loosen it to epsilon > greater than or equal to . Note that this might require > quite a lot of thougfht to get right. > - Specific suggestion (dumb-down): simply state that "continuous" > shall mean that the function "has no substantial jumps", or something > along those lines. My gut-feeling is that, again, with respect to the intended audience, we could probably keep this relatively informal. As a consequence, we should probably avoid the term "continuous" altogether. Perhaps the introduction of drift can move up to the introduction of the raw clock, discussing how the time perceived by the system and expressed via the raw clock differs from passage of wall time. It just felt better to do this as part of the introduction of adjusted raw time from a narrative perspective. > (3) Vocabulary (technical and editorial): use of the term "monotonic"=20 > - Description: Although I acknowledge that in 2.1, the draft gives > a(n implicit) definition of what it refers to when it uses the term=20 > "monotonic" (i.e. "continuous and strictly monotonically > increasing"), I still do not like it. This mention comes from the "monotonic clock" defined as one of the clock types in POSIX with a rather vague definition (leaving it unclear whether it refers to a raw clock or adjusted raw clock in our sense). As a result of that appearance, many people seem to use the term. I guess this warrants a longer discussion than just a drive-by mention. > If there is interest (if the current editors think it would make > things easier and not harder), I guess I would offer to work on the > draft as an additional editor. Many thanks for your kind offer. We=E2=80=99d be delighted to welcome you as an additional editor! Kind regard, Martin From nobody Thu Nov 16 08:09:40 2017 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A01126D05; Thu, 16 Nov 2017 08:09:39 -0800 (PST) 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 MNN9f86ibZut; Thu, 16 Nov 2017 08:09:35 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.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 00580120713; Thu, 16 Nov 2017 08:09:34 -0800 (PST) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vAGG8W74009740-vAGG8W76009740 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 17:08:32 +0100 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id EC3AD5ACD5C; Thu, 16 Nov 2017 17:08:31 +0100 (CET) In-Reply-To: <20171116102057.5a7c2df0@grisu.home.partim.org> References: <20171116102057.5a7c2df0@grisu.home.partim.org> To: Martin Hoffmann Cc: kristof.teichel@ptb.de, ntp@ietf.org, "ntp" MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Thu, 16 Nov 2017 17:08:28 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z34245_boundary_sign Archived-At: Subject: [Ntp] Antwort: Re: [NTP] Draft "On Implementing Time" 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, 16 Nov 2017 16:09:39 -0000 This is an S/MIME signed message. ---------z34245_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0058AA6BC12581DA_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0058AA6BC12581DA_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I will add some additional to Tal's and Kristof's comments to the draft=20 "draft-aanchal-time-implementation-guidance-00". Clause 2: - UTC is not a time but a time scale - UTC is steered towards UT1 and not solar time. See e.g. Sec. 4.6 of the=20 BCP (https://tools.ietf.org/html/draft-ietf-ntp-bcp-05#section-4.6). - The explanation of UTC seems to me much too over-simplified. This should = be dropped. Instead you could quote the definition of UTC given by the=20 BIPM: "The UTC scale is adjusted from International Atomic Time (TAI) by the=20 insertion of leap seconds according to the advice of the International=20 Earth Rotation and Reference Systems Service (IERS) to ensure approximate=20 agreement with the time derived from the rotation of the Earth."=20 [Citation: BIPM, URL:https://www.bipm.org/en/bipm-services/timescales/ ].=20 Alternatively you could quote the ITU recommendation=20 "Coordinated Universal Time (UTC): The time-scale maintained by the Bureau = International des Poids et Mesures (BIPM) and the International Earth=20 Rotation and Reference Systems Service (IERS), which forms the basis of a=20 coordinated dissemination of standard frequencies and time signals."=20 [Citation: ITU-R TF.686-3:(12/2013)]. Clause 2.2 - As Tal already mentioned, a clear definition of the used nomenclature is = necessary. Tal mentioned Dave's definition, which of course is correct.=20 But, since this documents aims to give general guidance in the field of=20 the timing, I suggest to adjust your language to the ITU recommendations=20 ITU-R TF.686-3:(12/2013). Hence,=20 - using "frequency difference" if you speak of clocks whose frequencies=20 differ, - using "frequency drift" if you mean the change of a clock's frequency=20 over time (the first derivative of the frequency). I would recommend not to use NTP as an example in 2.2 since NTP does not=20 provide a mean to synchronize the frequency of a clock. Instead it adjust=20 the clock's frequency in order to synchronize the clock's time. That is a=20 different goal and is therefore not comparable. You could use the term "Syntonization" [ITU-R TF.686-3:(12/2013)], if you=20 mean the adjustment of the clock's frequency. PTP does provide a syntonization mode. Thus, you might use PTP as an=20 example in this section. Clause 2.3. I don't like the term "Real time". It sounds like Real Time Clock (RTC)=20 which you would call "Raw time" (if I understand it right). This in short. I hope this might be useful. Dieter "ntp" schrieb am 16.11.2017 10:20:57: > Von: Martin Hoffmann > An: kristof.teichel@ptb.de > Kopie: ntp@ietf.org > Datum: 16.11.2017 10:21 > Betreff: Re: [Ntp] [NTP] Draft "On Implementing Time" > Gesendet von: "ntp" >=20 > Hi Kristof, >=20 > kristof.teichel@ptb.de wrote: > >=20 > > I have just given a read to the "On Implementing Time" draft ( > >=20 https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-interleaved-modes > > ).=20 > > There are a few issues that I'd like to raise. >=20 > Many thanks for reading the document and sharing your thoughts! >=20 > > (1) Vocabulary (technical): use of the term "time" > > - Description: I take issue with not explaining what the document > > means when in uses the term "time", specifically "a time", > > when properties like continuous, monotonic (separate issue, see > > below) are assigned. In these cases, it is heavily implied the "a > > time" is supposed to be a function (because the cited properties are > > usually applied to functions), but this is never stated, which I find > > problematic. For example, I still need to figure out what the domain > > and co-domain of the function are supposed to be. Naively I would > > assume that the co-domain is a subset (probably implementation > > specific) of "int" or "float". I would then assume that the domain > > is... well, "actual" time. Which brings me to my next issue with the > > used terminology: "time" becomes an overloaded term, it represents > > the abstract heuristic concept and then also some kind of function > > from this concept to a machine-appropriate value set. > > - Suggested remedy: edit the terminology to be consistent, > > - Specific suggestions for the remedy (even if this is deemed=20 > > insufficient, I still strongly advocate trying to implement the > > remedy in some other way): > > -- "Time" remains as the abstract heuristic concept (and is not=20 > > explained in the document). > > -- The kind of value that a machine can read and communicate (for=20 > > example a timestamp) could be called a "clocktime". The document > > should state this somewhere. How exactly "clocktime" is realized > > (int, float, ...) is implementation specific. The document might or > > might not go into that detail. > > -- The function that maps the current "time" to a "clocktime" is > > called a "clock". The document should state this somewhere. >=20 > The draft already somewhat distinguishes between the two "classes" of > definitions--wall time on the one side and the three remaining ones on > the other, even if it doesn?t call out that distinction. I think we can > make this more obvious by simply using the word "clock" instead of > "time" for the three concrete representations of time available to a > system. >=20 > We?ve been debating to what extent we should discuss the, for lack of a > better term, philosophical background of time, keeping in mind our > target audience. On the one hand, this is all very important and > interesting, on the other hand, we don?t want to scare away people > starting out with a lengthy treatise.=20 >=20 > > (2) Vocabulary (more editorial, with some technical implications): > > use of the term "continuous" > > - Description: since the co-domain of a "clock" (current term in the=20 > > document is "time", see above) is necessarily a discrete set, the > > notion of "continuity" causes some problems, since the usual > > definitions don't easily apply (basically, the function always has > > "jumps" in it, due to the discrete nature of the co-domain). > > - Suggestion: clean up the terminology and make it consistent, OR > > just dumb it down. > > - Specific suggestion (clean-up): have "continuous" mean that the > > function does not exhibit jumps greater than the "resolution" of the > > co-domain. Use epsilon-delta definition, but loosen it to epsilon > > greater than or equal to . Note that this might require > > quite a lot of thougfht to get right. > > - Specific suggestion (dumb-down): simply state that "continuous" > > shall mean that the function "has no substantial jumps", or something > > along those lines. >=20 > My gut-feeling is that, again, with respect to the intended audience, > we could probably keep this relatively informal. As a consequence, we > should probably avoid the term "continuous" altogether. Perhaps > the introduction of drift can move up to the introduction of the raw > clock, discussing how the time perceived by the system and expressed > via the raw clock differs from passage of wall time. It just felt > better to do this as part of the introduction of adjusted raw time > from a narrative perspective. >=20 > > (3) Vocabulary (technical and editorial): use of the term "monotonic"=20 > > - Description: Although I acknowledge that in 2.1, the draft gives > > a(n implicit) definition of what it refers to when it uses the term=20 > > "monotonic" (i.e. "continuous and strictly monotonically > > increasing"), I still do not like it. >=20 > This mention comes from the "monotonic clock" defined as one of the > clock types in POSIX with a rather vague definition (leaving it > unclear whether it refers to a raw clock or adjusted raw clock in > our sense). As a result of that appearance, many people seem to use the > term. I guess this warrants a longer discussion than just a drive-by > mention. >=20 > > If there is interest (if the current editors think it would make > > things easier and not harder), I guess I would offer to work on the > > draft as an additional editor. >=20 > Many thanks for your kind offer. We?d be delighted to welcome you as > an additional editor! >=20 > Kind regard, > Martin >=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 0058AA6BC12581DA_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi,

I will add some additional to Tal's and Kristof's comments to the draft "draft-aanchal-time-implementation= -guidance-00".


Clause 2:
- UTC is not a time but a time scale=
- UTC is steered towards UT1 and not solar time. See e.g. Sec. 4.6 of the BCP (https://tools.ietf.org/html/draft-ietf-ntp-bcp-05#sect= ion-4.6).
- The explanation of UTC seems to me much too over-simplified. This should be dropped. Instead you could quote the definition of UTC given by the BIPM:
"The UTC scale is adjusted from International Atomic Time (TAI) by the insertion of leap seconds according to the advice of the International Earth Rotation and Reference Systems Service (IERS) to ensure approximate agreement with the time derived from the rotation of the Earth." [Citation: BIPM, URL:https://www.bipm.org/en/bipm-services/timescales/ ].

Alternatively you could quote the ITU recommendation
"Coordinated Universal Time (UT= C): The time-scale maintained by the Bureau International des Poids et Mesures (BIPM) and the International Earth Rotation and Reference Systems Service (IERS), which forms the basis of a coordinated dissemination of standard frequencies and time signals." [Citation: ITU-R TF.686-3:(12/2013)].

Clause 2.2
- As Tal already mentioned, a clear definition of the used nomenclature is necessary. Tal mentioned Dave's definition, which of course is correct. But, since this documents aims to give general guidance in the field of the timing, I suggest to adjust your language to the ITU recommendations ITU-R TF.686-3:(12/2013). Hence,
- using "frequency difference&q= uot; if you speak of clocks whose frequencies differ,
- using "frequency drift" if you mean the change of a clock's frequency over time (the first derivati= ve of the frequency).

I would recommend not to use NTP as an example in 2.2 since NTP does not provide a mean to synchronize the frequency of a clock. Instead it adjust the clock's frequency in order to synchronize the clock's time. That is a different goal and is therefore not comparable.

You could use the term "Syntoni= zation" [ITU-R TF.686-3:(12/2013)], if you mean the adjustment of the clock's frequ= ency.

PTP does provide a syntonization mod= e. Thus, you might use PTP as an example in this section.

Clause 2.3.
I don't like the term "Real tim= e". It sounds like Real Time Clock (RTC) which you would call "Raw time&qu= ot; (if I understand it right).

This in short. I hope this might be useful.

Dieter






"ntp" <ntp-bounces@ietf.org> schrieb am 16.11.2017 10:20:57:

> Von: Martin Hoffmann <martin@opennetlabs.com>
> An: kristof.teichel@ptb.de
> Kopie: ntp@ietf.org
> Datum: 16.11.2017 10:21
> Betreff: Re: [Ntp] [NTP] Draft "On Impleme= nting Time"
> Gesendet von: "ntp" <ntp-bounces@i= etf.org>
>
> Hi Kristof,
>
> kristof.teichel@ptb.de wrote:
> >
> > I have just given a read to the "On Implementing Time" draft (
> > https://datatracker.ie= tf.org/doc/html/draft-mlichvar-ntp-interleaved-modes
> > ).
> > There are a few issues that I'd like to raise.
>
> Many thanks for reading the document and sharing your thoughts!
>
> > (1) Vocabulary (technical): use of the term "time"
> > - Description: I take issue with not explaining what the document=
> > means when in uses the term "time", specifically "a <property> time",
> > when properties like continuous, monotonic (separate issue, see > > below) are assigned. In these cases, it is heavily implied the "a
> > time" is supposed to be a function (because the cited proper= ties are
> > usually applied to functions), but this is never stated, which I find
> > problematic. For example, I still need to figure out what the domain
> > and co-domain of the function are supposed to be. Naively I would=
> > assume that the co-domain is a subset (probably implementation
> > specific) of "int" or "float". I would then assume that the domain
> > is... well, "actual" time. Which brings me to my next issue with the
> > used terminology: "time" becomes an overloaded term, it represents
> > the abstract heuristic concept and then also some kind of functio= n
> > from this concept to a machine-appropriate value set.
> > - Suggested remedy: edit the terminology to be consistent,
> > - Specific suggestions for the remedy (even if this is deemed
> > insufficient, I still strongly advocate trying to implement the > > remedy in some other way):
> >   -- "Time" remains as the abstract heuristic concept (and is not
> > explained in the document).
> >   -- The kind of value that a machine can read and communica= te (for
> > example a timestamp) could be called a "clocktime". The document
> > should state this somewhere. How exactly "clocktime" is realized
> > (int, float, ...) is implementation specific. The document might or
> > might not go into that detail.
> >   -- The function that maps the current "time" to a "clocktime" is
> > called a "clock". The document should state this somewh= ere.
>
> The draft already somewhat distinguishes between the two "classes= " of
> definitions--wall time on the one side and the three remaining ones on
> the other, even if it doesn’t call out that distinction. I think we can
> make this more obvious by simply using the word "clock" instead of
> "time" for the three concrete representations of time availa= ble to a
> system.
>
> We’ve been debating to what extent we should discuss the, for la= ck of a
> better term, philosophical background of time, keeping in mind our
> target audience. On the one hand, this is all very important and
> interesting, on the other hand, we don’t want to scare away peop= le
> starting out with a lengthy treatise.
>
> > (2) Vocabulary (more editorial, with some technical implications)= :
> > use of the term "continuous"
> > - Description: since the co-domain of a "clock" (current term in the
> > document is "time", see above) is necessarily a discrete set, the
> > notion of "continuity" causes some problems, since the usual
> > definitions don't easily apply (basically, the function always has
> > "jumps" in it, due to the discrete nature of the co-dom= ain).
> > - Suggestion: clean up the terminology and make it consistent, OR
> > just dumb it down.
> > - Specific suggestion (clean-up): have "continuous" mean that the
> > function does not exhibit jumps greater than the "resolution= " of the
> > co-domain. Use epsilon-delta definition, but loosen it to epsilon=
> > greater than or equal to <resolution>. Note that this might require
> > quite a lot of thougfht to get right.
> > - Specific suggestion (dumb-down): simply state that "contin= uous"
> > shall mean that the function "has no substantial jumps", or something
> > along those lines.
>
> My gut-feeling is that, again, with respect to the intended audience,<= br> > we could probably keep this relatively informal. As a consequence, we
> should probably avoid the term "continuous" altogether. Perhaps
> the introduction of drift can move up to the introduction of the raw > clock, discussing how the time perceived by the system and expressed > via the raw clock differs from passage of wall time. It just felt
> better to do this as part of the introduction of adjusted raw time
> from a narrative perspective.
>
> > (3) Vocabulary (technical and editorial): use of the term "m= onotonic"
> > - Description: Although I acknowledge that in 2.1, the draft gives
> > a(n implicit) definition of what it refers to when it uses the term
> > "monotonic" (i.e. "continuous and strictly monoton= ically
> > increasing"), I still do not like it.
>
> This mention comes from the "monotonic clock" defined as one of the
> clock types in POSIX with a rather vague definition (leaving it
> unclear whether it refers to a raw clock or adjusted raw clock in
> our sense). As a result of that appearance, many people seem to use the
> term. I guess this warrants a longer discussion than just a drive-by > mention.
>
> > If there is interest (if the current editors think it would make<= br> > > things easier and not harder), I guess I would offer to work on the
> > draft as an additional editor.
>
> Many thanks for your kind offer. We’d be delighted to welcome you as
> an additional editor!
>
> Kind regard,
> Martin
>
> =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<= font size=3D2>
 --=_alternative 0058AA6BC12581DA_=-- ---------z34245_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTYxNjA4MjlaMC8GCSqGSIb3DQEJ BDEiBCCScr/ZbjuaTcUfHTourrl3gGD+4vKQB4z0YIRPSx4wvzBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQDe7BFVH4sJv5OGEmNnAX8GCNl4 66fWGIiGdEzjpKrCcWIWtLXlW2emmFp206UGDWrtPY1fqLwlNUbszpHc5kD/q5+zz9O5wIC6AsQv 6o4FC2KjrSb9eGWgPiEocvoaUlEdaCu6sqTA2Mjdx7TfAsD0ns8CkJUhJO71mnQvbqHNeUrG7pDa suwZCbU3YnPpmHi4m6k3mN04Coa52A3ZJ7XxY3QTq+5jFflsOM2c/YBtQMxyoQNNlhGuBOU6ks31 ArT9aFt+c9NWSSkRLVaLTjquVDYPWp80AefSW0YbzOLWuyq8AH1C2aDcOTxK+OcNlFRgKIvXk5/q LVwZvCg+UfgnAAAAAA== ---------z34245_boundary_sign-- From nobody Thu Nov 16 09:35: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 B7AE9129AAA for ; Thu, 16 Nov 2017 09:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ccfGzp8B0IFh for ; Thu, 16 Nov 2017 09:35:42 -0800 (PST) Received: from smtp.ucolick.org (hunan.ucolick.org [128.114.23.233]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD1D129A8D for ; Thu, 16 Nov 2017 09:35:40 -0800 (PST) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 0A6FF272B; Thu, 16 Nov 2017 09:35:38 -0800 (PST) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) by smtp.ucolick.org (Postfix) with ESMTP id 0735F270B; Thu, 16 Nov 2017 09:35:38 -0800 (PST) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (Postfix) with ESMTP id F240C448; Thu, 16 Nov 2017 09:35:37 -0800 (PST) Received: (from sla@localhost) by geneva.ucolick.org (8.14.7/8.14.7/Submit) id vAGHZbxc010481; Thu, 16 Nov 2017 09:35:37 -0800 Date: Thu, 16 Nov 2017 09:35:37 -0800 From: Steve Allen To: NTP WG Message-ID: <20171116173537.GA10440@ucolick.org> References: <20171116102057.5a7c2df0@grisu.home.partim.org> 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) Archived-At: Subject: Re: [Ntp] [NTP] Draft "On Implementing Time" 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, 16 Nov 2017 17:35:44 -0000 On Thu 2017-11-16T17:08:28+0100 dieter.sibold@ptb.de hath writ: > - The explanation of UTC seems to me much too over-simplified. This should > be dropped. Instead you could quote the definition of UTC given by the > BIPM: > "The UTC scale is adjusted from International Atomic Time (TAI) by the > insertion of leap seconds according to the advice of the International > Earth Rotation and Reference Systems Service (IERS) to ensure approximate > agreement with the time derived from the rotation of the Earth." > [Citation: BIPM, URL:https://www.bipm.org/en/bipm-services/timescales/ ]. BIPM is currently responsible for the underlying atomic time scale, but the BIPM has never held the definition of UTC. The definition of UTC has always been managed by the ITU-R (previously known as the CCIR). Before the name UTC was applied this was in CCIR Recommendation 374 (1963) CCIR Recommendation 374-1 (1966) The broadcast time signals were changed to use leap seconds by CCIR Recommendation 460 (1970) and the name UTC was first applied in Recommendation 460-1 (1974) The current definition of UTC is ITU-R Recommendation TF.460-6 (2002-02) http://www.itu.int/rec/R-REC-TF.460/en -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From nobody Thu Nov 16 16:50: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 D91C512726E for ; Thu, 16 Nov 2017 16:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 3kv5W7JWNTZW for ; Thu, 16 Nov 2017 16:50:35 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.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 B60F9126CD8 for ; Thu, 16 Nov 2017 16:50:34 -0800 (PST) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vAH0nWHW006651-vAH0nWHY006651 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2017 01:49:32 +0100 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id E68435ACEBA; Fri, 17 Nov 2017 01:49:31 +0100 (CET) In-Reply-To: <20171116173537.GA10440@ucolick.org> References: <20171116102057.5a7c2df0@grisu.home.partim.org> <20171116173537.GA10440@ucolick.org> To: Steve Allen Cc: NTP WG MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Fri, 17 Nov 2017 01:49:25 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z59640_boundary_sign Archived-At: Subject: [Ntp] Antwort: Re: [NTP] Draft "On Implementing Time" 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, 17 Nov 2017 00:50:39 -0000 This is an S/MIME signed message. ---------z59640_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00048660C12581DB_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00048660C12581DB_= Content-Type: text/plain; charset="US-ASCII" Hi Steve, thanks for this information. Good point. I didn't claim that the BIPM owns the definition of UTC. But it is the organisation that is in charge to coordinate and maintain UTC (as also stated in TF.460-6). Therefore, at least in my opinion, it is a valid source of reference just like ITU-R TF.460-6 (2002-02). I pointed to ITU-R TF.686-3:(12/2013) because it is a glossary and contains defintion of further terms that are used in this draft. Also ITU-R TF.686-3:(12/2013) itself refers to ITU-R TF.460 in its definition of UTC. So in my opinion both recommendations are applicable. Dieter "ntp" schrieb am 16.11.2017 18:35:37: > Von: Steve Allen > An: NTP WG > Datum: 16.11.2017 18:35 > Betreff: Re: [Ntp] [NTP] Draft "On Implementing Time" > Gesendet von: "ntp" > > On Thu 2017-11-16T17:08:28+0100 dieter.sibold@ptb.de hath writ: > > - The explanation of UTC seems to me much too over-simplified. This should > > be dropped. Instead you could quote the definition of UTC given by the > > BIPM: > > "The UTC scale is adjusted from International Atomic Time (TAI) by the > > insertion of leap seconds according to the advice of the International > > Earth Rotation and Reference Systems Service (IERS) to ensure approximate > > agreement with the time derived from the rotation of the Earth." > > [Citation: BIPM, URL:https://www.bipm.org/en/bipm-services/timescales/ ]. > > BIPM is currently responsible for the underlying atomic time scale, > but the BIPM has never held the definition of UTC. The definition of > UTC has always been managed by the ITU-R (previously known as the > CCIR). > > Before the name UTC was applied this was in > CCIR Recommendation 374 (1963) > CCIR Recommendation 374-1 (1966) > The broadcast time signals were changed to use leap seconds by > CCIR Recommendation 460 (1970) > and the name UTC was first applied in > Recommendation 460-1 (1974) > > The current definition of UTC is > ITU-R Recommendation TF.460-6 (2002-02) > http://www.itu.int/rec/R-REC-TF.460/en > > -- > Steve Allen WGS-84 (GPS) > UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 > 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 > Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m > > _______________________________________________ > ntp mailing list > ntp@ietf.org > https://www.ietf.org/mailman/listinfo/ntp --=_alternative 00048660C12581DB_= Content-Type: text/html; charset="US-ASCII" Hi Steve,

thanks for this information. Good point.

I didn't claim that the BIPM owns the definition of UTC. But it is the organisation that is in charge to coordinate and maintain UTC (as also stated in TF.460-6). Therefore, at least in my opinion, it is a valid source of reference just like ITU-R TF.460-6 (2002-02). I pointed to ITU-R TF.686-3:(12/2013) because it is a glossary and contains defintion of further terms that are used in this draft. Also ITU-R TF.686-3:(12/2013) itself refers to ITU-R TF.460 in its definition of UTC. So in my opinion both recommendations are applicable.


Dieter



"ntp" <ntp-bounces@ietf.org> schrieb am 16.11.2017 18:35:37:

> Von: Steve Allen <sla@ucolick.org>
> An: NTP WG <ntp@ietf.org>
> Datum: 16.11.2017 18:35
> Betreff: Re: [Ntp] [NTP] Draft "On Implementing Time"
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> On Thu 2017-11-16T17:08:28+0100 dieter.sibold@ptb.de hath writ:
> > - The explanation of UTC seems to me much too over-simplified. This should
> > be dropped. Instead you could quote the definition of UTC given by the
> > BIPM:
> > "The UTC scale is adjusted from International Atomic Time (TAI) by the
> > insertion of leap seconds according to the advice of the International
> > Earth Rotation and Reference Systems Service (IERS) to ensure approximate
> > agreement with the time derived from the rotation of the Earth."
> > [Citation: BIPM, URL:https://www.bipm.org/en/bipm-services/timescales/ ].
>
> BIPM is currently responsible for the underlying atomic time scale,
> but the BIPM has never held the definition of UTC.  The definition of
> UTC has always been managed by the ITU-R (previously known as the
> CCIR).
>
> Before the name UTC was applied this was in
> CCIR Recommendation 374 (1963)
> CCIR Recommendation 374-1 (1966)
> The broadcast time signals were changed to use leap seconds by
> CCIR Recommendation 460 (1970)
> and the name UTC was first applied in
> Recommendation 460-1 (1974)
>
> The current definition of UTC is
> ITU-R Recommendation TF.460-6 (2002-02)
> http://www.itu.int/rec/R-REC-TF.460/en
>
> --
> Steve Allen                    <sla@ucolick.org>              WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
> 1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
> Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
 --=_alternative 00048660C12581DB_=-- ---------z59640_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTcwMDQ5MjZaMC8GCSqGSIb3DQEJ BDEiBCBnVRGzDMKfYVPtzoi0e1gWFhmH5aJR9FyL8VVkfO9qyzBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQBhvG/dx83bqniT6lGgt5w0/33b RXM36hlMLfP1oBHlJGte06wvAyl6ZpaFp37QfkPY7xW8YfJ9e/vqIK2liY389Xn90L5s2QJG5f/Y W+SRTjNd7wLzEkRXU6K6n2BItoImHkokVsHEGTfWMIWt7XDHv/+YOnDQXJyWveMPTGP6TlJJQmpU cgXDQzB32FJbtBJ/DN5KGsP6DZOF5g8E6vMS9vpIg2SoIOFEfniWlcAEA9mLfiHORl/f0ChRzMVW TNiWYJmzcqf8qXAx5K5dNfeWYXg1PN/9Jxis+Qb/KgtoMU0Ci9t2LO529X+t3PXFbjiUGQdGBany olRQPo4goFCBAAAAAA== ---------z59640_boundary_sign-- From nobody Tue Nov 21 09:46: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 259C21294FF; Tue, 21 Nov 2017 09:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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_H2=-2.8, 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 AC0NxxiIDBrZ; Tue, 21 Nov 2017 09:46:54 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0075.outbound.protection.outlook.com [104.47.38.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F451293E4; Tue, 21 Nov 2017 09:46:53 -0800 (PST) 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=CVq0lKVusGxBPkztkwlKa4yWRxkdlWH0LrB3rcXlRqE=; b=B7c+TmD+RW4WSUK2USBo0P8puoPyMyvj0NfMlI4drTDsCcjIsRG6yH8ojsZQssWcpohYYS4Dec/T9bmAZUf39J/t8A3Fgjpld+DKdj+d6RRw3N4a00B1tc3isB1+zkvNPGjyLMr6Z+8N2EcjlbIhrfSvL9k2CQ2rEIM9EfjEOBA= Received: from BN6PR06MB2452.namprd06.prod.outlook.com (10.173.21.16) by BN6PR06MB2452.namprd06.prod.outlook.com (10.173.21.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 17:46:52 +0000 Received: from BN6PR06MB2452.namprd06.prod.outlook.com ([10.173.21.16]) by BN6PR06MB2452.namprd06.prod.outlook.com ([10.173.21.16]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 17:46:52 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" , "tictoc@ietf.org" Thread-Topic: Doodle poll for NTP virtual interim - Dec 2017 Thread-Index: AQHTYvC2XGLK+vaRB0CgvAoQT1Xa0Q== Date: Tue, 21 Nov 2017 17:46:52 +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: [125.25.127.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB2452; 6:k8k0JDeGlLphCeuSagZSAp4l1g+n/6AsGiji1iI8Vyw9p+F9V89ZQLb2M36ouLE5PmE9X0Ai2iq/HhAnnwgJBbkAVlbJxtnVeuGRB2z7fscijm0I9MI4POoV3xhtLDMmjIJ0vKoLxIvXyHOmxiWqqbw7spw1+z0HDKN5vxqoVLwjOwMVYza+uGb+E1BJT1SiXd0AmcTyHqt8F2wHsUyEpcO8OVOw/GMZybREQf5gKXr0QB+8dp1TVjAOFelZqV65sawTT6gQ+wX30DRDOEfLzwEzO81z2A5g5oZKZGogBit6U26L2h/+kSonLjXPOcYRYFoPAS18jCiXVWDWWsP5T/rK004+n4mONQHT6fAH3Mo=; 5:M+tJIUIeXsd6dPMpjNtbnqqXewQrDYvlysj04Z5xZRlGmyfaWBR3MOs1JvNW7MKc3o5K2dr3rRDLmhsQECiky3X60nwD9Jwf5ByFXi/cL6/owE85rANHOMtzgvrUDtm01Mo4aySX5BUjAmKGxvLuQVivjEdBi6wMOk5QCc90qbw=; 24:8fy67PVb8m+DogfOekU8NWZB7bLqKRxeFcFpjLgEiv2xMgwVoGn7MXTKTF+Qa8BRxTcU9JloYAZEGw0Iz9zdvYhVl9qmObKjrhQa0YQU41I=; 7:znENCOyyXCKxRo4RjDyz+xhH5i+867UNnua/h7B1czJ/oiy7Q2Q1DofIR27BD3iwK9xBm9lbvw7y+rUySBARDuPObwUw916Tc7uqoGZO7bF8D71aosXV1sJ2zq3e41QksllJXewQQeKq5Kl2nH/tB3qPLwuxlQIJb14SFCFFCi0u1pCfEe72ECnClUGnfD9oWKKN/z/mJnFEGZQ4BuV+Dtw6JNy2kEynEjoh7SRklxzkZCaJZyjdSG+2lUY6UQ0Y x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7b4bfd6c-3309-4310-3cf9-08d53107d95e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR06MB2452; x-ms-traffictypediagnostic: BN6PR06MB2452: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60409825278598); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB2452; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB2452; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39830400002)(199003)(189002)(6306002)(54896002)(236005)(3280700002)(8936002)(53936002)(6512007)(5660300001)(6436002)(83716003)(101416001)(606006)(8676002)(6506006)(81156014)(99286004)(450100002)(81166006)(2906002)(33656002)(106356001)(66066001)(50986999)(77096006)(68736007)(3660700001)(110136005)(105586002)(6486002)(54356999)(14454004)(478600001)(189998001)(36756003)(7736002)(558084003)(966005)(97736004)(25786009)(3846002)(86362001)(6116002)(102836003)(2501003)(316002)(82746002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB2452; H:BN6PR06MB2452.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: multipart/alternative; boundary="_000_B0A2B329EFDA46789BCB95498B21A26Cisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4bfd6c-3309-4310-3cf9-08d53107d95e X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 17:46:52.1969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2452 Archived-At: Subject: [Ntp] Doodle poll for NTP virtual interim - Dec 2017 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, 21 Nov 2017 17:46:56 -0000 --_000_B0A2B329EFDA46789BCB95498B21A26Cisocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We would like to have a virtual interim meeting in December. Please respond= to the following doodle poll by Tuesday 28 November to assist with schedul= ing. https://doodle.com/poll/qd8p5gbdqua9q8ew Regards, Karen --_000_B0A2B329EFDA46789BCB95498B21A26Cisocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <0CFF50DF6376CF4B8E103EB6FC226525@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Folks,

We would like to have a virtual interim meeting in December. Please respond= to the following doodle poll by Tuesday 28 November to assist with schedul= ing. 

https://doo= dle.com/poll/qd8p5gbdqua9q8ew

Regards,
Karen --_000_B0A2B329EFDA46789BCB95498B21A26Cisocorg_-- From nobody Wed Nov 22 09:35: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 D5B051294A6; Wed, 22 Nov 2017 09:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 GNVzUMefmlIA; Wed, 22 Nov 2017 09:35:33 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.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 7BBD01200C5; Wed, 22 Nov 2017 09:35:33 -0800 (PST) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vAMHYVfS026867-vAMHYVfU026867 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Nov 2017 18:34:31 +0100 Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 60C4E5AFB08; Wed, 22 Nov 2017 18:34:31 +0100 (CET) To: ntp@ietf.org, tictoc@ietf.org MIME-Version: 1.0 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 22 Nov 2017 18:34:29 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary=-------z32744_boundary_sign Archived-At: Subject: [Ntp] Minutes from the NTP WG session at IETF 100 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, 22 Nov 2017 17:35:39 -0000 This is an S/MIME signed message. ---------z32744_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00608A98C12581E0_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00608A98C12581E0_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The minutes from the NTP/TICTOC meeting at IETF 100 are available under: https://datatracker.ietf.org/meeting/100/materials/minutes-100-ntp/ Dieter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D NTP/TICTOC Joint Meeting November 13th, 2017, 13:30-15:30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 NTP WG Chairs: Karen O'Donoghue, Dieter Sibold TICTOC WG Chairs: Karen O'Donoghue, Yaakov Stein (absent) Note taker: Tal Mizrahi Jabber: Kyle Rose =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NTP Session =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 CHAIR SLIDES ------------ Presenter: Karen O'Donoghue=20 Slides:=20 https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-agenda-an= d-note-well/ =20 Summary: - Karen presented the new note well. - Control Messages Protocol for Use with Network Time Protocol Version 4 = draft: - There are open questions how operators are currently using mode 6 - Would anyone be willing to help out Brian with the mode 6 draft?=20 - There are question about version numbering - Question about the necessity to add additional commands to the=20 mode 6 messages - Robert Nagy: I volunteer. - BCP=20 - is in the shepherding write-up stage - NTP extension field draft:=20 - We will be putting together a consensus call about this issue=20 after further discussion with the authors. - Harlan: the authors got together a couple of times. - Karen: the authors still need to agree. There seem to be two=20 alternatives, and we want to be able to present the options to the working = group. =20 =20 MESSAGE AUTHENTICATION CODE FOR THE NETWORK TIME PROTOCOL --------------------------------------------------------- No slides were presented. =20 Discussion: - Aanchal: will add the security considerations section in the next=20 version of the draft. - Tal: another comment was regarding whether this MAC could be included=20 in an extension field. - Aanchal: that was already discussed on the mailing list. - Tal: another issue was there should be a subsection about=20 interoperability with previous implementations. =20 =20 NETWORK TIME SECURITY (NTS) --------------------------- Presenter: Dieter Sibold https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-network-t= ime-security-for-the-network-time-protocol/ =20 Discussion: - Kyle Rose: what is the plan for modes other than client/server? - Dieter: In the last interim meeting we talked about moving the other=20 modes to another draft in the future. - Daniel Franke: I expect to write an experimental draft about these other = modes. - Karen: is there a time frame for moving forward? - Dieter: not at this time. If we could have an interim meeting, we can=20 talk about a plan in the interim. - Karen: it could be great if we could have a hackathon effort around NTS=20 in IETF 101 in London. =20 =20 A YANG DATA MODEL FOR NTP ------------------------- Presenter: Anil Kumar (remote) https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-a-yang-da= ta-model-for-ntp/ =20 Discussion: - Harlan: I am assuming there should be compatibility between the YANG=20 model interface, the mode 6 interface, and the SNMP MIB interface.=20 - Greg: why does this need to be compatible? - Harlan: functionally equivalent, not necessarily compatible. - Robert Nagy: I agree that it needs to be equivalent, but not compatible. = When can we finally get this released? We don't want to continue to update = this. - Greg: we want to standardize the base, and then we will be able to add=20 extensions in the future. - Karen: What is your view on the compatibility with mode 6? - Anil: we did not try to have compatibility with mode 6. We believe it is = functionally equivalent to the MIB. - Karen: Harlan, do you believe compatibility with mode 6 is really=20 required? It seems that it is not a design objective. - Harlan: we want to make it easier on the user by having the three=20 mechanisms as similar as possible. - Karen: it is not reasonable to require these three to be compatible, as=20 mode 6 and the MIB go back a long time. - Harlan: let?s try to reach functional equivalence. - Anil: I will look into it with the other authors. =20 =20 =20 GUIDELINES FOR DEFINING PACKET TIMESTAMP FORMATS ------------------------------------------------ Presenter: Tal Mizrahi https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-packet-ti= mestamp-formats/ =20 Discussion: - Greg: I believe this work is valuable. I would like to suggest clear=20 terminology that distinguishes resolution from accuracy. Also suggest to=20 discuss how to migrate to a higher accuracy. Another aspect that should be = discussed is how the control plane communicates the timestamp format. In=20 future we might need more resolution as provided by the truncated PTP=20 timestamps. We might add a foresight discussion how to migrate to higher=20 resolution timestamps. - Karen: what is the time frame for the next steps? - Tal: we hope to complete the open issues by the next IETF meeting and be = ready for WG last call. =20 =20 NTP INTERLEAVED MODES --------------------- Presenter: Aanchal Malhotra https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-ntp-inter= leaved-modes/ =20 Discussion: - Greg: when you say ?improve the accuracy?, what do you mean? - Aanchal: the accuracy of the timestamp captured by the client or server. - Greg: when you timestamp in software, there may be nondeterministic=20 error. The further you move from the demon, the less accurate it is. - Rich Salz: the time stamping is already in the kernel space. The further = you move from the demon, the more accurate. - Tal: this is very similar to the PTP Follow=5Fup messages. PTP uses=20 Sequence ID to match the timestamp and the corresponding event message. Is = there something similar in the proposed mechanism? - Aanchal: yes. The receiver verifies the origin timestamp and the=20 transmit timestamp. - Tal: from a security perspective, it looks like if a MAC verification=20 fails, you should also ignore the previous and next packet, as they are=20 bound by the interleaved timestamps. Please consider this and add text=20 about it to the draft. - Harlan: there was a discussion about where you get the most accurate=20 timestamp: closest to the interface, or further from the demon. Both are=20 correct, depending on the specific system. There was quite a bit of work=20 by Dave Mills about Interleave mode. Regarding the MAC: either the MAC=20 works or not, and we drop if it does not work. Interleave mode is a=20 wonderful thing. - Kristof Teichel: this work is very important. Clarification question:=20 does the server have to keep per-client states? - Aanchal: yes. - Robert: what you did is great. There are security issues that we need to = think about. If we could avoid adding an additional field for that, it=20 would be great. - Greg: regarding PTP Follow=5Fup messages: what is the frequency of the=20 messages from the client to the server? By delaying the information to the = next query, we increase the interval. If we had used something similar to=20 Follow=5Fup messages, the information would be used immediately. - Karen: please summarize this proposal on the mailing list. - Aanchal: delay is not an issue here. - Harlan: interleave mode is most useful in symmetric mode, and less=20 useful in client/server mode. =20 ON IMPLEMENTING TIME -------------------- Presenter: Aanchal Malhotra https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-on-implem= enting-time/ =20 Discussion: - Greg: a timestamp is not necessarily based on wall clock time. It can be = relative, or can be based on any reference. - Willem Toorop: a timestamp is a point in time expressed in wall time. - Greg: it is important to agree on the dictionary. - Harlan: it is unfair to describe some of these issues in the context of=20 NTP. - Kristof: this work is important. Where can the document be found? - Aanchal: it is on the agenda. - Kristof: please use the term monotonic more carefully ? need to define=20 it. - Greg: only NTP is used as a reference to this draft. - Tal: it is important to clearly define the scope of the document, and=20 the target audience. Another issue is that the intended status should=20 probably be informational. - Karen: the scope is very important. - Ethan Grossman: one of the things that was not clear was what the draft=20 was focusing on: implementation considerations, or security aspects. - Karen: can we have an update to the draft before we start call for=20 adoption? - Aanchal: we would be happy if people could send their comments on the=20 mailing list. =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TICTOC Session =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 CHAIR SLIDES ------------ Presenter: Karen O'Donoghue=20 Slides:=20 https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-agenda-an= d-note-well/ =20 A YANG DATA MODEL FOR IEEE 1588v2 --------------------------------- Presenter: Yuanlong Jiang https://datatracker.ietf.org/meeting/100/materials/slides-100-tictoc-yang-d= ata-model-for-ieee-1588v2/ =20 Discussion: - Karen: one remaining unresolved issue. Once we resolve that issue, there = is probably no need for another WG last call. - Yuanlong: we are looking into it, and I will update the mailing list=20 once we resolve it. - Suresh Krishnan: has this been reviewed by a YANG expert? Will need to=20 be. - Karen: there was no official YANG doctor review, but it was reviewed by=20 YANG experts. We can do a formal YANG doctor review. - Suresh: please do that when the document is ready. - Yuanlong: we sent version 05 to the NETMOD working group. We received=20 comments on the mailing list. We have not received any formal comments=20 from a YANG doctor. =20 ------------------------------------- Dr. Dieter Sibold Physikalisch-Technische Bundesanstalt Q.42 - Zeitverteilung mittels IP QM-Verantwortlicher der Stelle IT Bundesallee 100=20 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: dieter.sibold@ptb.de --=_alternative 00608A98C12581E0_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The minutes from the NTP/TICTOC meeting at IETF 100 are available under:

https://datatracke= r.ietf.org/meeting/100/materials/minutes-100-ntp/

Dieter

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
NTP/TICTOC Joint Meeting
November 13th, 2017, 13:30-15:30
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

NTP WG Chairs: Karen O'Donoghue, Dieter Sibold
TICTOC WG Chairs: Karen O'Donoghue, Yaakov Stein (absent)
Note taker: Tal Mizrahi
Jabber: Kyle Rose

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
NTP Session
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIR SLIDES
------------
Presenter: Karen O'Donoghue
Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-agenda-= and-note-well/

Summary:
-   Karen presented the new note well.
-   Control Messages Protocol for Use with Network Time Protocol Versi= on 4 draft:
   -   There are open questions how operators are currently using mode 6
   -   Would anyone be willing to help out Brian with the mode 6 draft?
   -   There are question about version numbering
   -   Question about the necessity to add additional comma= nds to the mode 6 messages
   -   Robert Nagy: I volunteer.
-   BCP
   -   is in the shepherding write-up stage
-   NTP extension field draft:
   -   We will be putting together a consensus call about this issue after further discussion with the authors.
   -   Harlan: the authors got together a couple of times.<= br>    -   Karen: the authors still need to agree. There seem to be two alternatives, and we want to be able to present the options to the working group.


MESSAGE AUTHENTICATION CODE FOR THE NETWORK TIME PROTOCOL
---------------------------------------------------------
No slides were presented.

Discussion:
-   Aanchal: will add the security considerations section in the next version of the draft.
-   Tal: another comment was regarding whether this MAC could be inclu= ded in an extension field.
-   Aanchal: that was already discussed on the mailing list.
-   Tal: another issue was there should be a subsection about interope= rability with previous implementations.


NETWORK TIME SECURITY (NTS)
---------------------------
Presenter: Dieter Sibold
https://datatracker.ietf.org/meeting/100/materials= /slides-100-ntp-network-time-security-for-the-network-time-protocol/=

Discussion:
- Kyle Rose: what is the plan for modes other than client/server?
- Dieter: In the last interim meeting we talked about moving the other modes to another draft in the future.
- Daniel Franke: I expect to write an experimental draft about these other modes.
- Karen: is there a time frame for moving forward?
- Dieter: not at this time. If we could have an interim meeting, we can talk about a plan in the interim.
- Karen: it could be great if we could have a hackathon effort around NTS in IETF 101 in London.


A YANG DATA MODEL FOR NTP
-------------------------
Presenter: Anil Kumar (remote)
h= ttps://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-a-yang-dat= a-model-for-ntp/

Discussion:
- Harlan: I am assuming there should be compatibility between the YANG model interface, the mode 6 interface, and the SNMP MIB interface.
- Greg: why does this need to be compatible?
- Harlan: functionally equivalent, not necessarily compatible.
- Robert Nagy: I agree that it needs to be equivalent, but not compatible. When can we finally get this released? We don't want to continue to update this.
- Greg: we want to standardize the base, and then we will be able to add extensions in the future.
- Karen: What is your view on the compatibility with mode 6?
- Anil: we did not try to have compatibility with mode 6. We believe it is functionally equivalent to the MIB.
- Karen: Harlan, do you believe compatibility with mode 6 is really require= d? It seems that it is not a design objective.
- Harlan: we want to make it easier on the user by having the three mechani= sms as similar as possible.
- Karen: it is not reasonable to require these three to be compatible, as mode 6 and the MIB go back a long time.
- Harlan: let’s try to reach functional equivalence.
- Anil: I will look into it with the other authors.



GUIDELINES FOR DEFINING PACKET TIMESTAMP FORMATS
------------------------------------------------
Presenter: Tal Mizrahi
ht= tps://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-packet-time= stamp-formats/

Discussion:
- Greg: I believe this work is valuable. I would like to suggest clear terminology that distinguishes resolution from accuracy. Also suggest to discuss how to migrate to a higher accuracy. Another aspect that should be discussed is how the control plane communicates the timestamp format. In future we might need more resolution as provided by the truncated PTP timestamps. We might add a foresight discussion how to migrate to higher resolution timestamps.
- Karen: what is the time frame for the next steps?
- Tal: we hope to complete the open issues by the next IETF meeting and be ready for WG last call.


NTP INTERLEAVED MODES
---------------------
Presenter: Aanchal Malhotra
https= ://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-ntp-interleave= d-modes/

Discussion:
- Greg: when you say “improve the accuracy”, what do you mean?<= br> - Aanchal: the accuracy of the timestamp captured by the client or server.<= br> - Greg: when you timestamp in software, there may be nondeterministic error. The further you move from the demon, the less accurate it is.
- Rich Salz: the time stamping is already in the kernel space. The further you move from the demon, the more accurate.
- Tal: this is very similar to the PTP Follow=5Fup messages. PTP uses Seque= nce ID to match the timestamp and the corresponding event message. Is there something similar in the proposed mechanism?
- Aanchal: yes. The receiver verifies the origin timestamp and the transmit timestamp.
- Tal: from a security perspective, it looks like if a MAC verification fails, you should also ignore the previous and next packet, as they are bound by the interleaved timestamps. Please consider this and add text about it to the draft.
- Harlan: there was a discussion about where you get the most accurate timestamp: closest to the interface, or further from the demon. Both are correct, depending on the specific system. There was quite a bit of work by Dave Mills about Interleave mode. Regarding the MAC: either the MAC works or not, and we drop if it does not work. Interleave mode is a wonderf= ul thing.
- Kristof Teichel: this work is very important. Clarification question: does the server have to keep per-client states?
- Aanchal: yes.
- Robert: what you did is great. There are security issues that we need to think about. If we could avoid adding an additional field for that, it would be great.
- Greg: regarding PTP Follow=5Fup messages: what is the frequency of the messages from the client to the server? By delaying the information to the next query, we increase the interval. If we had used something similar to Follow=5Fup messages, the information would be used immediately.
- Karen: please summarize this proposal on the mailing list.
- Aanchal: delay is not an issue here.
- Harlan: interleave mode is most useful in symmetric mode, and less useful in client/server mode.

ON IMPLEMENTING TIME
--------------------
Presenter: Aanchal Malhotra
https:= //datatracker.ietf.org/meeting/100/materials/slides-100-ntp-on-implementing= -time/

Discussion:
- Greg: a timestamp is not necessarily based on wall clock time. It can be relative, or can be based on any reference.
- Willem Toorop: a timestamp is a point in time expressed in wall time.
- Greg: it is important to agree on the dictionary.
- Harlan: it is unfair to describe some of these issues in the context of NTP.
- Kristof: this work is important. Where can the document be found?
- Aanchal: it is on the agenda.
- Kristof: please use the term monotonic more carefully – need to def= ine it.
- Greg: only NTP is used as a reference to this draft.
- Tal: it is important to clearly define the scope of the document, and the target audience. Another issue is that the intended status should proba= bly be informational.
- Karen: the scope is very important.
- Ethan Grossman: one of the things that was not clear was what the draft was focusing on: implementation considerations, or security aspects.
- Karen: can we have an update to the draft before we start call for adopti= on?
- Aanchal: we would be happy if people could send their comments on the mailing list.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
TICTOC Session
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIR SLIDES
------------
Presenter: Karen O'Donoghue
Slides: https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-agenda-= and-note-well/

A YANG DATA MODEL FOR IEEE 1588v2
---------------------------------
Presenter: Yuanlong Jiang
https://datatracker.ietf.org/meeting/100/materials/slides-100-ticto= c-yang-data-model-for-ieee-1588v2/

Discussion:
- Karen: one remaining unresolved issue. Once we resolve that issue, there is probably no need for another WG last call.
- Yuanlong: we are looking into it, and I will update the mailing list once we resolve it.
- Suresh Krishnan: has this been reviewed by a YANG expert? Will need to be.
- Karen: there was no official YANG doctor review, but it was reviewed by YANG experts. We can do a formal YANG doctor review.
- Suresh: please do that when the document is ready.
- Yuanlong: we sent version 05 to the NETMOD working group. We received comments on the mailing list. We have not received any formal comments from a YANG doctor.


-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Zeitverteilung mittels IP
QM-Verantwortlicher der Stelle IT
Bundesallee 100
D-38116 Braunschweig
Tel:    +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de
 --=_alternative 00608A98C12581E0_=-- ---------z32744_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIp0gIBATEPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEHAaCCJsYw ggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNE ZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDky MzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv b3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5Dlv NV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggr JSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgB SV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ 7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoDNNWO WwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1Ud EwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT /lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjyt nv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQK bbo5YyiGkvMYhNj70c8FVmRXMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYD VQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkw NzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7T uKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1MjwrrFDa1sPe g5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs671x1Udrb8zH57nGY MsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W5OFhmHZhyJF81j4A4pFQ h+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT 1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0B AQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756AbrsptJh6 sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pM SyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijch vllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9Wgb RGOiWrqnNVmh5XAFmw4jV5mUCm26OWMohpLzGITY+9HPBVZkVzCCBNUwggO9oAMCAQICCFBOxvU9 EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2No ZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3MDkyMzU5MDBaMFoxCzAJ BgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQD ExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0 iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvS xhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2 kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU 28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGGMIIBgjAOBgNVHQ8BAf8E BAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPX F+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFswWTARBg8rBgEEAYGtIYIs AQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQDATAPBg0rBgEEAYGtIYIs AQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9wa2kwMzM2LnRlbGVz ZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGowLAYIKwYBBQUHMAGGIGh0 dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAChi5odHRwOi8vcGtpMDMz Ni50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQBjICj9 nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1gvuEKgFJvWa7Zi+ywgZd bj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxSPtLJatOQI25JZzW+f01W pOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhjpyQAELC7/E6vbi84u6VX ST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321e6UC8STFJGMRNMxakyAq eYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIE1TCCA72gAwIBAgIIUE7G9T0RtGQwDQYJKoZIhvcN AQELBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNV BAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTE0MDcyMjEyMDgyNloXDTE5MDcwOTIzNTkwMFowWjELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4g UENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u 9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFsso NTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90 D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8zs9sP xRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY +SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOCAYYwggGCMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMw EgYDVR0TAQH/BAgwBgEB/wIBAjBiBgNVHSAEWzBZMBEGDysGAQQBga0hgiwBAQQCAjARBg8rBgEE AYGtIYIsAQEEAwAwEQYPKwYBBAGBrSGCLAEBBAMBMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGB rSGCLB4wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9ybC9EVF9S T09UX0NBXzIuY3JsMHgGCCsGAQUFBwEBBGwwajAsBggrBgEFBQcwAYYgaHR0cDovL29jc3AwMzM2 LnRlbGVzZWMuZGUvb2NzcHIwOgYIKwYBBQUHMAKGLmh0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv Y3J0L0RUX1JPT1RfQ0FfMi5jZXIwDQYJKoZIhvcNAQELBQADggEBAGMgKP2cIYZyvjlGWTkyJbyp AZsNzMp9QZyGbQpuLLMTWXWxM5IbYScW/8Oy1TWC+4QqAUm9ZrtmL7LCBl1uP27jAVpbykNjXJW2 4TGnH9UHX03mZYJOMvnDfHpLzU1cdO4h8nUC7FI+0slq05AjbklnNb5/TVak7Mwvz7ehl6hyPsm8 QNZapAg91ryCw7e3Mo6xLI5qbbc1AhnP9TlEWGOnJAAQsLv8Tq9uLzi7pVdJP9huUG8sl5bcHUaa ZYnPrszy5dmfU7M+oS+SqdgLxoQfBMbrHuiffbV7pQLxJMUkYxE0zFqTICp5iDolQpCpZTt8htMS FSMp/CzazDlbVBcwggU9MIIEJaADAgECAgcXr/adVkv+MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMTQwNjA1MTQwNTAyWhcNMTkwNzA5MjM1OTAw WjBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVz YW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6 MEMiFr0xY6SEzYcDG3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9 WqIzoT5PzG07qJWblbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgS h/qds5SM6CUgwMeuJ42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6 X55QT+kWaAoQf6qJyJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwID AQABo4IB9zCCAfMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAow CDAGBgRVHSAAMB0GA1UdDgQWBBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHSMEGDAWgBRJt8bP 6D0ff+pEexMp9/EKcD7eZDAVBgNVHREEDjAMgQpwa2lAcHRiLmRlMIGIBgNVHR8EgYAwfjA9oDug OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5k Zm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0G CSqGSIb3DQEBCwUAA4IBAQCo3hebMpEocLPJTOlDMAmSzpxK3SA1ftaQqodbMncOi9WkeICQlmIv rQxGCq8Be/6hKtIrbFOhRtSzQi870glJRj7dhZaHC+WOgT5tP5Nkgwpgl4k4pQDXPPrwmaI6cSYD a/LpprQzBNjEQMdQqkeanpD0WU9U1pOPFIMfIrxh2cy8mBpIAMuZqMHbMyPNDZk/YN4r3b2DcBrQ wL/tHerp6Vc7n9WqO+3cm7Fa4AxL9q2KeItyYe0Cws2KZNz4IuiMjQAclNL0PhTEqIzkD/EiK6Ag 1qcH7o3ktpmakvL2RzSZA71irCfONRgh/+ixfuMu6YA5uzyA8SYfwyFQcABdMIIFPTCCBCWgAwIB AgIHF6/2nVZL/jANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0g RzAxMB4XDTE0MDYwNTE0MDUwMloXDTE5MDcwOTIzNTkwMFowaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALwKwoM5KsNizAGLlN/FSU4MhgQvj6frr8Odi5rSOjBDIha9MWOkhM2HAxt8+TUqIWYrHZy+ 27vBHuzBQ902V9Y1QYnv/1DQCal2x51MxPIWyWAkecnW/VqiM6E+T8xtO6iVm5W4nXK2VXAkBHn/ VdQmkcn17qokkzoIm6jgyz/fDe4zCCJs9oqVIDHaBsjoEof6nbOUjOglIMDHrieNkKWDaLfa4tSC gMHsoSCGt0wDbLuerHMvhXNvl1jn7LiJnni3GoruhyT5Ol+eUE/pFmgKEH+qiciV7/G/5+pdZ5ky FNgGNgeRJzv6yE/g1vjCcu+/xzvu67cGs57p7VzIMrcCAwEAAaOCAfcwggHzMBIGA1UdEwEB/wQI MAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUxIDQ bigVaDFa7HBfeI7hMEM46jQwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0R BA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHK MIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1Aw RwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqN4XmzKR KHCzyUzpQzAJks6cSt0gNX7WkKqHWzJ3DovVpHiAkJZiL60MRgqvAXv+oSrSK2xToUbUs0IvO9IJ SUY+3YWWhwvljoE+bT+TZIMKYJeJOKUA1zz68JmiOnEmA2vy6aa0MwTYxEDHUKpHmp6Q9FlPVNaT jxSDHyK8YdnMvJgaSADLmajB2zMjzQ2ZP2DeK929g3Aa0MC/7R3q6elXO5/Vqjvt3JuxWuAMS/at iniLcmHtAsLNimTc+CLojI0AHJTS9D4UxKiM5A/xIiugINanB+6N5LaZmpLy9kc0mQO9YqwnzjUY If/osX7jLumAObs8gPEmH8MhUHAAXTCCBaIwggSKoAMCAQICDBxmO6qdufc5yhZ6iDANBgkqhkiG 9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUg QnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRl MB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoM JVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsMBFEuNDIxGjAY BgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA +AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvchop87cCwv80aZEbmU3as54egQEMGn NFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc/BDkm1Nl5WYKh/DxN6sUhZxorbb4 Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn1wYHMsC+tAcFflcMXF2sDMZHkYuq 5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLuB22sT17XPJ2U/9tuFN/sxAPR0/N4 y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4ICSTCCAkUwQAYDVR0gBDkwNzARBg8r BgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0T BAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1Ud DgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjq NDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAjBgorBgEEAYI3FAIDoBUME3NpYm9s ZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9w dGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRi LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSBujCBtzAzBggrBgEFBQcwAYYnaHR0 cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMD8GCCsGAQUFBzAChjNodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwPwYIKwYBBQUHMAKG M2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro5OgIcWSpW4i4AQ1wEwyDUrdB1XWK GjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx327mV4K8PE8z7fg5l2ittYNs0nXlOB QevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcIIXTwaN6AVr2NVKEuH3qwpgOUSlJJ1 5ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfqm6GWqpXfQ6NLAvWYcI8ltSKgdnCw Rmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r296qoKUBRDCCBaIwggSKoAMCAQIC DBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5 c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJ KoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTE2MTIwNjEzMzMxNFoXDTE5MDcwOTIzNTkwMFowaDEL MAkGA1UEBhMCREUxLjAsBgNVBAoMJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3Rh bHQxDTALBgNVBAsMBFEuNDIxGjAYBgNVBAMMEURyLiBEaWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AOQrmrEQ2k8s9su/TVvmdF46YbL2MuF6OvnrjjKaJIkBvch op87cCwv80aZEbmU3as54egQEMGnNFkp1fF4bics4TJdEpND116l+jbi5DCtA3hHP/spV1aQZBDc /BDkm1Nl5WYKh/DxN6sUhZxorbb4Y0nmSxnK2ctIwuF4Qdibsw7GE2YLvWF4tlzSCGbDjSy2agSn 1wYHMsC+tAcFflcMXF2sDMZHkYuq5IHwng8GBQFhsldYl1fk2sB2/hVRLYU205qaj13H94WjfDLu B22sT17XPJ2U/9tuFN/sxAPR0/N4y4/IgMnOaP30VU0FMmULd7qJg0WST5D5kwgMhwIDAQABo4IC STCCAkUwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGBrSGCLAIBBAMBMA8G DSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQHn42zKDpvJi1bsJ4OVk2A9liUFjAfBgNVHSMEGDAW gBTEgNBuKBVoMVrscF94juEwQzjqNDBEBgNVHREEPTA7gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZaAj BgorBgEEAYI3FAIDoBUME3NpYm9sZDAxQHBhZC5wdGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHHBggrBgEFBQcBAQSB ujCBtzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ MD8GCCsGAQUFBzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEADaSfgrrQZx9eiQrCK7kgJMpLstro 5OgIcWSpW4i4AQ1wEwyDUrdB1XWKGjA8/KwExSBP9a+dcdW+ACjX7TyURQPLqRTOkoPc9dafRx32 7mV4K8PE8z7fg5l2ittYNs0nXlOBQevRbYYP4XUOMYohFWfHpDwEg3ExmoArb2HaQCzKhq/2VcII XTwaN6AVr2NVKEuH3qwpgOUSlJJ15ORb6TD4p1G2W6XT3jk3tOa8nRaOkI5hqpPvLfbPEibn+Bfq m6GWqpXfQ6NLAvWYcI8ltSKgdnCwRmqdh1Ba/KWGdm41PDtQIx58vgbZGfN5GKJrp+OwS5D+/e/r 296qoKUBRDGCAuMwggLfAgEBMHkwaTELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBDQTEZMBcGCSqGSIb3DQEJ ARYKcGtpQHB0Yi5kZQIMHGY7qp259znKFnqIMA0GCWCGSAFlAwQCAQUAoIIBOzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMjIxNzM0MzBaMC8GCSqGSIb3DQEJ BDEiBCApWMG73Uf22YMsjZ22WWLXwO/R3jonAxo9TmozlXTFoTBDBgkqhkiG9w0BCQ8xNjA0MAcG BSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAKBggqhkiG9w0DBzANBggqhkiG9w0DAgIBKDCBigYLKoZI hvcNAQkQAgsxe6B5MGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5p c2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBw dGIuZGUCDBxmO6qdufc5yhZ6iDANBgkqhkiG9w0BAQEFAASCAQDKyhAcNHZ6dAcSUXCnXHNiac92 K5ZScqfRWsmi5AE+d+8KhG0FNTxo6tLrIcqcuwnb12iS8KiDKSy36tICH366hYxFBvTF07Xk7gtD 7sMUMwqv1e0DEFK1NYCakBrq1JCCqM/Q1S1gZbPRdU0H97fH9BAQ9wqLVN5K9wqihG/yHzJas2Uh Nboaow2jUIoBqnAd7S+2KhTVMdXEEZfS7A3CVSokM9yzOtS6PNmWNg+ivv/QJ+86gE2izJ6/Qvn5 Bmy1HqQttnGxgz3IQLr2PuT9V3UxicB0rHn1o5W2K8ZLCU3eCPg3+8RUS8DwrM3kekCZY2O9vDyJ L4z+Hcu77glrAAAAAA== ---------z32744_boundary_sign-- From nobody Thu Nov 23 07:39:07 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 255AD12EB13 for ; Thu, 23 Nov 2017 07:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsk1fXnQyz26 for ; Thu, 23 Nov 2017 07:39:04 -0800 (PST) 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 8D59F12EB11 for ; Thu, 23 Nov 2017 07:39:04 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B428DA7E7; Thu, 23 Nov 2017 15:39:03 +0000 (UTC) Received: from localhost (unknown [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BD2B7620A2; Thu, 23 Nov 2017 15:39:02 +0000 (UTC) Date: Thu, 23 Nov 2017 16:39:01 +0100 From: Miroslav Lichvar To: kristof.teichel@ptb.de Cc: Aanchal Malhotra , ntp@ietf.org Message-ID: <20171123153901.GA11846@localhost> References: <20171113145607.GB20898@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171113145607.GB20898@localhost> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 23 Nov 2017 15:39:03 +0000 (UTC) Archived-At: Subject: Re: [Ntp] Draft on Interleave Mode -- Keeping "preemptive" per-client state 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, 23 Nov 2017 15:39:06 -0000 On Mon, Nov 13, 2017 at 03:56:07PM +0100, Miroslav Lichvar wrote: > On Mon, Nov 13, 2017 at 03:26:07PM +0100, kristof.teichel@ptb.de wrote: > > This is completely reasonable if it can be expected that every "basic" > > request (or at least a very large portion of them) will eventually be > > followed up upon with an "interleave" request. > > It does, however, seem like serious overkill for any association where > > such a follow-up call can not be expected. > > > > I would therefore advise some additional communication, to get rid of the > > cases where state is kept unnecessarily. > One option would be to check if the origin timestamp is not zero > before saving/updating the state. Majority of public NTP traffic is > from various SNTP clients, which send packets with zero origin > timestamp. Full NTP clients using the basic mode and following the > data minimization draft will do that too. And if there was a need to avoid saving timestamps for old NTP clients, which set the origin timestamp in their requests to the last transmit timestamp of the server, I think the server could encode an RX bit in the timestamps themselves in their low-order bits below precision of the clock. For example, all receive timestamps of the server could end with 1 and transmit timestamps end with 0. When the server receives a request with an origin timestamp ending with 0, it will know it's an NTP client using the basic mode and it does not need to save any timestamps for the interleaved mode. To make the bit random, the server could add to it a hash of a secret key, the other bits, and the IP address of the client for instance. This could be extended to all bits below the precision to make it less likely a random origin timestamp will be interpreted as a receive timestamp. I'm not sure if we need to specify how exactly the bit should be encoded. I'm considering to add to the end of the client/server section of the draft something like this: The server MAY limit saving of the receive and transmit timestamps to requests which have an origin timestamp specific to the interleaved mode in order to not waste resources on clients using the basic mode. Such an optimization delays the first interleaved response of the server by one exchange. A check for a non-zero origin timestamp works with clients that implement the NTP data minimization [I-D.ietf-ntp-data-minimization]. To detect requests in the basic mode from clients that do not implement the data minimization, the server can encode in low-order bits of the receive and transmit timestamps below precision of the clock a bit indicating whether the timestamp is a receive timestamp. If the server receives a request with a non-zero origin timestamp which does not indicate it is receive timestamp of the server, the request is in the basic mode and it is not necessary to save the new receive and transmit timestamp. What do you think? -- Miroslav Lichvar From nobody Mon Nov 27 05:23:22 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 83A29128B4E for ; Mon, 27 Nov 2017 05:23:19 -0800 (PST) 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 n8yrmWjIPuc0 for ; Mon, 27 Nov 2017 05:23:15 -0800 (PST) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.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 B8928127A91 for ; Mon, 27 Nov 2017 05:23:13 -0800 (PST) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vARDM6kk020774-vARDM6km020774 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Nov 2017 14:22:06 +0100 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 1DCE65B1E52; Mon, 27 Nov 2017 14:22:05 +0100 (CET) In-Reply-To: References: To: Sharon Goldberg Cc: ntp@ietf.org MIME-Version: 1.0 Message-ID: From: kristof.teichel@ptb.de Date: Mon, 27 Nov 2017 14:22:04 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00496F29C12581E5_=" Archived-At: Subject: Re: [Ntp] Sharon Goldberg comments on 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: Mon, 27 Nov 2017 13:23:20 -0000 Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00496F29C12581E5_= Content-Type: text/plain; charset="US-ASCII" Hello all, I wanted to go into a few key issues that Sharon raised in her review of NTS that still have us unsure of how to proceed (either because we cannot reach agreement between the authors/editors, or because we feel we need to justify our decision towards the working group or both). For the rest of the discussion, I would like to establish a few fundamentals that we have never explicitly talked about. Let me know if there is significant reason for discourse over these: A) Interests of the participants Inherently, participants in NTS-secured NTP communication have very different interests depending on their role. - Any *client* has an interest to get the most reliable, most accurate measurements possible reagrding its offset from a chosen time server. This interest benifits the client itself. The client does not inherently want to or have to do anyhting to benefit the server. - Any *server* has a very simple interest: to serve clients. It does not have any interests that benefit itself (except, implicitly, to not cause harm, to itself or third parties by using NTS). Interestingly, this means that often, the server's behavior must be more closely regulated than the client's. After all, if a client wants to go against its own interest, this is hardly preventable. But for any instance where the bahavior of the server affects the client's interest, I think that normative language is in order. B) Strategic motivation The NTS draft's overall strategic motivation is twofold: - We want make sure that participants (=clients, since everything other than client-server mode is out) can rely on the timing information that they use to synchronize their clock. - We want to make sure that implementations following this draft are additionally satisfying good practice with regards to being internet protocols. Basically anything else is out of scope, and anything that falls under the second bullet point is often highly debatable. All the items that are currently under "1.1 Objectives" are fundamentally just means to achieve either of the two ends listed above. I am currently thinking about whether I would like to make this more clear in the document -- opinions are welcome. C) The way the document communicates My understanding of an RFC candidate is that, most of all, it should be instructive. It should tell an implementor what to do, as unambiguously as possible, but also only as detailed as necessary. A secondary responsibility that we have is to explain what is going on, so that the reader has enough context to see how it is supposed to work and compare the actual contents of the document to their expectation. But, again, this should IMO only be as detailed as necessary. A tertiary goal that will sometimes be nice to have is to justify why and how what we specify actually works as intended, or why and how it fulfills the requirements we state initially. But this cannot be a requirement, otherwise the document will simply become too lengthy, AND significant parts of it would simply be unnecessary for most implementors/informed readers. D) Attacker model and DoS I have always worked from the assumption that NTS needed to be secure under a Dolev-Yao model (meaning that the modeled attacker can control all aspects of the communication). As kind of a corollary from this, I have always regarded any attack vector that gives at worst such capabilities to an attacker as low-priority material. Such attack vectors include, but are not limited to: - DoS of a *single* client participant (meaning that it won't be able to successfully synchronize its clock via NTS-secured NTP anymore) by bombarding it (or its server) with packets - DoS of a server (and therefore multiple clients) for limited amounts of time (even though I have to admit that this is more severe) - Clever use of fragmentation in order to achieve observer capabilities, or basically anything that bossts an attacker's capability towards up to Dolev-Yao capabilities Well, now for the issues that remain from the feedback. I am omitting large parts of Sharon's text. This is only supposed to mean that we the editors have a good sense on how to proceed about the points raised there, one way or another. For the remaining issues, I am going to format my discussion starters as replies in line. Best regards, Kristof "ntp" schrieb am 31.08.2017 19:13:52: > Von: Sharon Goldberg > An: ntp@ietf.org > Datum: 31.08.2017 19:14 > Betreff: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp > Gesendet von: "ntp" > > Review of NTS. > [...] > > Section 1.2: Says: > > However, client-server mode also has more > relaxed security needs, because only the client requires replay > protection: it is harmless for servers to process replayed packets. > > This is false. With a broad statement like such as "it is 100% harmless, period", I agree that it is false. However, I stand by the statement that it is harmless in the context that is harmless in our scope. A replay attack on the client (if not protected against) could lead the client to falsely accept a timing packet as authentic even though it could be in a completely wrong timing context. Just replay an otherwise authentic packet a minute/an hour/a day... later, and you can wreak havoc if the client has no concept of "a reply to this request was already received" and therefore no reason to drop the packet. In this context, a replay attack on the server is not in the same league as a replay attack on the client. Actually, it isn't even really playing the same game. (See issues B) and D) int this mail's header) So how do we proceed? I am not opposed to going into this issue in a few (!) words, weakening the statement that it is harmless to something that is effectively "it is not a potential immediate catastrophe". I do not, however, believe that it is worth going into the damage that the server can suffer from replay attacks performed on it. > It can be harmful for a server to process replayed packets if that > server keeps client state in order to perform rate limiting with a > KoD. Specifically, an adversary can replay client packets at high > rate to the server, in order to trigger rate-limint restrictions at > the server and cause the server to send a "RATE" KoD to the client. > Once the client receives this KoD, it will slow down or even stop > its communications with the server. In other words, this is a DoS attack. Scaling-wise, I do not think that it makes sense to treat this. Yes, any form of rate-limiting is prone to causing issues like this. Also, replay protection doesn't seem to do anything here, other than to save the attacker the hassle of simply inventing new packets for the client (remember that rate limiting should be done before any kind of authentication checks, so valid MACs aren't actually useful to have). > This is CVE-2015-7705 which we called the "priming the pump" attack > in our NDSS'15 paper: > > https://eprint.iacr.org/2015/1020.pdf > > Thus, I suggest that the draft include some language targeted at > servers that do perform rate limiting with the KoD. Those servers > MAY take advantage of NTS's replay protection to stop the Priming > the Pump attack. In other words, these servers MAY track the > client's unique identifiers and making sure that they are not > reused, as a way of preventing the priming the pump attack. I am > suggesting the use of MAY because this can be resource intensive for > the server. (But, a data structure like a bloom filter could be > used to minimize the overhead at the server of checking uniqueness > of "unique identifiers"). > > I also suggest adding some text to the security considerations, > explaining that when the server uses (1) rate limiting with the KoD > but (2) does not use NTS's replay protections, then the server is > vulnerable to the Priming the Pump attack of CVE-2015-7705. This is something that I might be convinced of. I kind of see it as an argument for why per-client rate limiting is systemically a problematic idea though. > [...] > Section 5: > > As a point of presentation: I had trouble getting a high level view > of the protocol from reading Section 5. Some issues confused me > that I think should be defined up front. In other words, I think > Section 5 should start with some prose (even a new subsection) that > gives a detailed overview of the protocol. > > Pointing out some specific confusions of mine. > > - There are several "numbers" defined in this document, and it is > hard for the reader to disambiguate between them. Specifically, > there is the "Next Protocol number" and the "Field Type" and the > "Record Number". The start of Section 5 should start by telling the > reader what are the different "fields" and "types", and each of > their purposes. I also suggest providing references to the relevant > IANA Considerations in Section 8. > > - This section would benefit by showing a ladder presenting the > sequence of communications and message types that go back and forth > during a typical NTS exchange. Yes, I think we could agree on this. > > - I'm not clear if the C, record type, and body length fields > depicted in Figure 1 need to be authenticated by the AEAD > authenticator. Maybe this should be spelled out more clearly. > > **** > > Nowhere in the document do a see an explicit statement about when > the client is allowed to start taking time from an NTS-secured > server. I think the draft should spell this out, at the very > minimum with a SHOULD requirement, and possibly even a MUST. To do > this, it would help to have a ladder that shows the protocol flow, > and spells out in what point in the flow the client can start taking time. I think we have to declare this as outside of our scope, especially since NTP is not the only way of manipulating your computer's clock. The best I think we could do is to point out that time data cannot be asserted as authentic/secure before the initial key exchange is completed. Here, I honestly think this follows trivially from any form of diagram and should be easy to see even without one. So with Issue C) from the mail header in mind, I doubt that it is a good idea to spend words on this. > [...] > > 5.1.6 Cookies. > > Earlier on this list there was discussion on whether or not the > draft should specify normative requirements on cookies. Personally, > I support that view that we should place normative requirements on > cookies, because an insecure cookie implementation would break the > security of the whole protocol. > > That said, what is a show stopper in my opinion, is a lack of > specification in the draft of what properties are required from the > cookie. At the very least, we want to make sure that the cookie > does not leak the C2S and S2C keys to an observer (or a man in the middle). I do agree that this is an instance where normative language is called for (see Issue A) in the mail header). However, it is really difficult to mandate anything that ensures an abstract requirement (like "do not leak a given key") and stays instructive. For example, does it count as not leaking if I encrypt with a provenly unsecure algorithm? How am I supposed to know which algorithms are okay? Personally, I believe that this means we should actually mandate one or more specific secure formats for the cookie (e.g. the one described/recommended in the doc). But I think that consensus on this issue is far from reached. So how do we proceed? I would like the WG to give their opinioins on this issue in some explicit form, so that consensus can be reached and we at least know that there was a form of conscious decision. > If I have misunderstood, and this confidentiality is provided > because the cookie is encrypted (as a MUST) by the AEAD scheme, then > the draft should make this point more clear in section 5.1.6. No, you have not misunderstood. The encryption layer you mention is not the one that protects against key leakage (the cookie is, at another point, sent in cleartext). > Also, is there a requirement that cookies be different across > different clients? That each cookie used by a client is unique? At > the very least these requirements should be spelled out as a MUST > somewhere. If SHOULD is used, then a discussion of the risks of not > adhering to these requirements should be provided. I am honestly unsure about the effort of discussing this in the document, for the simple reason that it is absolutely not specific to NTS. Citing this would be a 100% preferable action IMO. If no citable document can be found, then I do not know how to proceed. > If this is somewhere in the draft already, and I missed then, then > apologies. But this text should be referenced in Section 5.1.6. > > ****** > --=_alternative 00496F29C12581E5_= Content-Type: text/html; charset="US-ASCII" Hello all,

I wanted to go into a few key issues that Sharon raised in her review of NTS that still have us unsure of how to proceed (either because we cannot reach agreement between the authors/editors, or because we feel we need to justify our decision towards the working group or both).

For the rest of the discussion, I would like to establish a few fundamentals that we have never explicitly talked about.
Let me know if there is significant reason for discourse over these:


A) Interests of the participants

Inherently, participants in NTS-secured NTP communication have very different interests depending on their role.
  - Any *client* has an interest to get the most reliable, most accurate measurements possible reagrding its offset from a chosen time server. This interest benifits the client itself. The client does not inherently want to or have to do anyhting to benefit the server.
  - Any *server* has a very simple interest: to serve clients. It does not have any interests that benefit itself (except, implicitly, to not cause harm, to itself or third parties by using NTS).

Interestingly, this means that often, the server's behavior must be more closely regulated than the client's.
After all, if a client wants to go against its own interest, this is hardly preventable.
But for any instance where the bahavior of the server affects the client's interest, I think that normative language is in order.


B) Strategic motivation

The NTS draft's overall strategic motivation is twofold:
    - We want make sure that participants (=clients, since everything other than client-server mode is out) can rely on the timing information that they use to synchronize their clock.
    - We want to make sure that implementations following this draft are additionally satisfying good practice with regards to being internet protocols.
Basically anything else is out of scope, and anything that falls under the second bullet point is often highly debatable.

All the items that are currently under "1.1 Objectives" are fundamentally just means to achieve either of the two ends listed above.
I am currently thinking about whether I would like to make this more clear in the document -- opinions are welcome.


C) The way the document communicates

My understanding of an RFC candidate is that, most of all, it should be instructive. It should tell an implementor what to do, as unambiguously as possible, but also only as detailed as necessary.
A secondary responsibility that we have is to explain what is going on, so that the reader has enough context to see how it is supposed to work and compare the actual contents of the document to their expectation. But, again, this should IMO only be as detailed as necessary.
A tertiary goal that will sometimes be nice to have is to justify why and how what we specify actually works as intended, or why and how it fulfills the requirements we state initially. But this cannot be a requirement, otherwise the document will simply become too lengthy, AND significant parts of it would simply be unnecessary for most implementors/informed readers.


D) Attacker model and DoS

I have always worked from the assumption that NTS needed to be secure under a Dolev-Yao model (meaning that the modeled attacker can control all aspects of the communication).
As kind of a corollary from this, I have always regarded any attack vector that gives at worst such capabilities to an attacker as low-priority material.
Such attack vectors include, but are not limited to:
  - DoS of a *single* client participant (meaning that it won't be able to successfully synchronize its clock via NTS-secured NTP anymore) by bombarding it (or its server) with packets
  - DoS of a server (and therefore multiple clients) for limited amounts of time (even though I have to admit that this is more severe)
  - Clever use of fragmentation in order to achieve observer capabilities, or basically anything that bossts an attacker's capability towards up to Dolev-Yao capabilities


Well, now for the issues that remain from the feedback.
I am omitting large parts of Sharon's text. This is only supposed to mean that we the editors have a good sense on how to proceed about the points raised there, one way or another.
For the remaining issues, I am going to format my discussion starters as replies in line.


Best regards,
Kristof



"ntp" <ntp-bounces@ietf.org> schrieb am 31.08.2017 19:13:52:

> Von: Sharon Goldberg <goldbe@cs.bu.edu>
> An: ntp@ietf.org
> Datum: 31.08.2017 19:14
> Betreff: [Ntp] Sharon Goldberg comments on draft-ietf-ntp-using-nts-for-ntp
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
>
> Review of NTS.
>
[...]
>
> Section 1.2:  Says: 
>
>     However, client-server mode also has more
>    relaxed security needs, because only the client requires replay
>    protection: it is harmless for servers to process replayed packets.
>    
> This is false. 

With a broad statement like such as "it is 100% harmless, period", I agree that it is false.
However, I stand by the statement that it is harmless in the context that is harmless in our scope.

A replay attack on the client (if not protected against) could lead the client to falsely accept a timing packet as authentic even though it could be in a completely wrong timing context. Just replay an otherwise authentic packet a minute/an hour/a day... later, and you can wreak havoc if the client has no concept of "a reply to this request was already received" and therefore no reason to drop the packet.

In this context, a replay attack on the server is not in the same league as a replay attack on the client. Actually, it isn't even really playing the same game.
(See issues B) and D) int this mail's header)

So how do we proceed?
I am not opposed to going into this issue in a few (!) words, weakening the statement that it is harmless to something that is effectively "it is not a potential immediate catastrophe". I do not, however, believe that it is worth going into the damage that the server can suffer from replay attacks performed on it.


> It can be harmful for a server to process replayed packets if that
> server keeps client state in order to perform rate limiting with a
> KoD. Specifically, an adversary can replay client packets at high
> rate to the server, in order to trigger rate-limint restrictions at
> the server and cause the server to send a "RATE" KoD to the client.
> Once the client receives this KoD, it will slow down or even stop
> its communications with the server.  In other words, this is a DoS attack.

Scaling-wise, I do not think that it makes sense to treat this.
Yes, any form of rate-limiting is prone to causing issues like this.
Also, replay protection doesn't seem to do anything here, other than to save the attacker the hassle of simply inventing new packets for the client (remember that rate limiting should be done before any kind of authentication checks, so valid MACs aren't actually useful to have).

> This is CVE-2015-7705 which we called the "priming the pump"  attack
> in our NDSS'15 paper:
>
> https://eprint.iacr.org/2015/1020.pdf
>
> Thus, I suggest that the draft include some language targeted at
> servers that do perform rate limiting with the KoD.  Those servers
> MAY take advantage of NTS's replay protection to stop the Priming
> the Pump attack.  In other words, these servers MAY track the
> client's unique identifiers and making sure that they are not
> reused, as a way of preventing the priming the pump attack. I am
> suggesting the use of MAY because this can be resource intensive for
> the server.  (But, a data structure like a bloom filter could be
> used to minimize the overhead at the server of checking uniqueness
> of "unique identifiers").
>
> I also suggest adding some text to the security considerations,
> explaining that when the server uses (1) rate limiting with the KoD
> but (2) does not use NTS's replay protections, then the server is
> vulnerable to the Priming the Pump attack of CVE-2015-7705.

This is something that I might be convinced of.
I kind of see it as an argument for why per-client rate limiting is systemically a problematic idea though.

>
[...]
> Section 5:
>
> As a point of presentation: I had trouble getting a high level view
> of the protocol from reading Section 5.  Some issues confused me
> that I think should be defined up front.  In other words, I think
> Section 5 should start with some prose (even a new subsection) that
> gives a detailed overview of the protocol.
>
> Pointing out some specific confusions of mine.
>
> - There are several "numbers" defined in this document, and it is
> hard for the reader to disambiguate between them. Specifically,
> there is the "Next Protocol number" and the "Field Type" and the
> "Record Number". The start of Section 5 should start by telling the
> reader what are the different "fields" and "types", and each of
> their purposes.  I also suggest providing references to the relevant
> IANA Considerations in Section 8.
>
> - This section would benefit by showing a ladder presenting the
> sequence of communications and message types that go back and forth
> during a typical NTS exchange.

Yes, I think we could agree on this.

>
> - I'm not clear if the C, record type, and body length fields
> depicted in Figure 1 need to be authenticated by the AEAD
> authenticator.  Maybe this should be spelled out more clearly.
>
> ****
>
> Nowhere in the document do a see an explicit statement about when
> the client is allowed to start taking time from an NTS-secured
> server.  I think the draft should spell this out, at the very
> minimum with a SHOULD requirement, and possibly even a MUST.  To do
> this, it would help to have a ladder that shows the protocol flow,
> and spells out in what point in the flow the client can start taking time.

I think we have to declare this as outside of our scope, especially since NTP is not the only way of manipulating your computer's clock.
The best I think we could do is to point out that time data cannot be asserted as authentic/secure before the initial key exchange is completed.
Here, I honestly think this follows trivially from any form of diagram and should be easy to see even without one. So with Issue C) from the mail header in mind, I doubt that it is a good idea to spend words on this.

>
[...]
>
> 5.1.6  Cookies.
>
> Earlier on this list there was discussion on whether or not the
> draft should specify normative requirements on cookies.  Personally,
> I support that view that we should place normative requirements on
> cookies, because an insecure cookie implementation would break the
> security of the whole protocol. 
>
> That said, what is a show stopper in my opinion, is a lack of
> specification in the draft of what properties are required from the
> cookie.  At the very least, we want to make sure that the cookie
> does not leak the C2S and S2C keys to an observer (or a man in the middle).

I do agree that this is an instance where normative language is called for (see Issue A) in the mail header).
However, it is really difficult to mandate anything that ensures an abstract requirement (like "do not leak a given key") and stays instructive.
For example, does it count as not leaking if I encrypt with a provenly unsecure algorithm? How am I supposed to know which algorithms are okay?

Personally, I believe that this means we should actually mandate one or more specific secure formats for the cookie (e.g. the one described/recommended in the doc).

But I think that consensus on this issue is far from reached.

So how do we proceed?
I would like the WG to give their opinioins on this issue in some explicit form, so that consensus can be reached and we at least know that there was a form of conscious decision.
  
> If I have misunderstood, and this confidentiality is provided
> because the cookie is encrypted (as a MUST) by the AEAD scheme, then
> the draft should make this point more clear in section 5.1.6.

No, you have not misunderstood.
The encryption layer you mention is not the one that protects against key leakage (the cookie is, at another point, sent in cleartext).
 
> Also, is there a requirement that cookies be different across
> different clients? That each cookie used by a client is unique?  At
> the very least these requirements should be spelled out as a MUST
> somewhere.  If SHOULD is used, then a discussion of the risks of not
> adhering to these requirements should be provided.

I am honestly unsure about the effort of discussing this in the document, for the simple reason that it is absolutely not specific to NTS.
Citing this would be a 100% preferable action IMO. If no citable document can be found, then I do not know how to proceed.
 
> If this is somewhere in the draft already, and I missed then, then
> apologies. But this text should be referenced in Section 5.1.6.
>
> ******
>
--=_alternative 00496F29C12581E5_=-- From nobody Tue Nov 28 05:40: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 9DF011250B8 for ; Tue, 28 Nov 2017 05:01:51 -0800 (PST) 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, 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 Nq4ODDbLhF8F for ; Tue, 28 Nov 2017 05:01:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233E11243F6 for ; Tue, 28 Nov 2017 05:01:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CEBE6B80FCA; Tue, 28 Nov 2017 05:01:38 -0800 (PST) To: mills@udel.edu, jrmii@isc.org, jack.burbank@jhuapl.edu, william.kasch@jhuapl.edu, suresh@kaloom.com, terry.manderson@icann.org, dieter.sibold@ptb.de, odonoghue@isoc.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: marcel@telka.sk, ntp@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171128130138.CEBE6B80FCA@rfc-editor.org> Date: Tue, 28 Nov 2017 05:01:38 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 28 Nov 2017 05:40:15 -0800 Subject: [Ntp] [Editorial Errata Reported] RFC5905 (5189) 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, 28 Nov 2017 13:01:52 -0000 The following errata report has been submitted for RFC5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5189 -------------------------------------- Type: Editorial Reported by: Marcel Telka Section: 6 Original Text ------------- | 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th | | | | | | Century | Corrected Text -------------- | 31 Dec 2000 | 51,909 | 0 | 3,187,209,600 | Last day 20th | | | | | | Century | Notes ----- 20th Century was from 1901 to 2000. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5905 (draft-ietf-ntp-ntpv4-proto-13) -------------------------------------- Title : Network Time Protocol Version 4: Protocol and Algorithms Specification Publication Date : June 2010 Author(s) : D. Mills, J. Martin, Ed., J. Burbank, W. Kasch Category : PROPOSED STANDARD Source : Network Time Protocol Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Nov 28 20:58: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 DE5E2128DF2; Tue, 28 Nov 2017 20:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 JVC5abiE5LOc; Tue, 28 Nov 2017 20:58:35 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0069.outbound.protection.outlook.com [104.47.42.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651361201F2; Tue, 28 Nov 2017 20:58:35 -0800 (PST) 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=7oJooUAtbVlH3k4U/OooHNNYCnGWMAm2AV0TNGi+yDs=; b=qavvLI+Csr9KzvPe3CDFXw1TBQLeAJHxWQYteWSki/2pPy+8BVn9yKuxahit4mJd2lUQcooAIvEELx5ZNznGwJyAj7bnRPDwvyQ0Od6XEW51rI8ytdZ2EX34N5VP8/aC7RCGnhtXLbgvuaEvPFtmSw01MG1bTtilNm7ZczMBR6Q= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 04:58:34 +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.0260.007; Wed, 29 Nov 2017 04:58:34 +0000 From: Karen O'Donoghue To: "ntp@ietf.org" , "tictoc@ietf.org" CC: "iesg-secretary@ietf.org" Thread-Topic: Joint NTP/TICTOC virtual interim meeting (Tuesday, 12 December, 1700-1830 UTC) Thread-Index: AQHTaM61fXVnCVvAe0udDSsnk+2yyA== Date: Wed, 29 Nov 2017 04:58:34 +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: [173.44.72.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2456; 6:qrIlIM2CAFTFYAo4avs6RhTIfGfFe0GdmfQ/2dV6mc2HeaBEuRoN9wgJagAOVg0aAcQKnz1cJ+AXbQC93kv+wMNXW2pXqLyLaE6ucTxd93qrZeb7Mc6rjnp99ZRVIgjBmRlU48xjPMl3gmq63vgFHrKanrAryggmt5Q57/2sFGKT09FHda9LocKMsT/mxLKRTw84oJZZk5T/HKaLIRD5vOfYP1kBXjvkFPywrbgsEt82GrHGorPWWBkK3X54udbdW6lGlbN6mVQrj/u9IA+bv2ocNN6RhCS7tNF10cMVSa8/CrEtbUYjEOcT3p9If+s5yb6wlXdKsT3XsY8t/O6lbMdyt88xb8t8QQw92zbsFyg=; 5:OhtiiVjKVsTGx8S/48cgisay//pFzkBevZHnEot8cpGV13ufGeKGL7d9JsrPcl9aKRxZjq8UW7hWcFmDonplT8+hsXUswKro7PebN0BLeDvw2vEzEPcewvpMSdXZqDDBcMO8fLNqBwLbK30R7yv2N8iAKL5xDbkgM3GE3MT7MxI=; 24:Z7hX+u8D3ak0LDb9BbCsaZTm9W2je4gyZH0yYpS/2JfGY28UYJlUqeb8znTlkbhq+oAO3nBGebYZcwzTjSZ0RN4/j/7sTKvBASSSU28IYo8=; 7:MFWljd0TIZem1A9/SUB1ii57vFdYlHts5cuA9jZGk8Ls/EAwFr/DpJ1vUlNSgwfTlRxmwJT/+xJ2g9+lbOyXi6LeBzYKNNSCxYTWNvaDKJHBRt5YIuA7FcGNhszQP5sbyKMc+YmjEj1tDm/aQr4SL+Z3zuVLA0FY5PIFUnxO4teT2SL2PAiz5d/1UIgKt/nPSimUOeBRzwr6ZID2JcTKI3Oz6PU6bAm/kGdgsEW7hNiZGpdCV/aCNqTqBLciUj4c x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7037cc73-f6a4-41de-f7e0-08d536e5d820 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603265); SRVR:CY4PR06MB2456; x-ms-traffictypediagnostic: CY4PR06MB2456: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(257447070540367); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011); SRVR:CY4PR06MB2456; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR06MB2456; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(376002)(366004)(346002)(39224004)(199003)(189002)(3846002)(6116002)(102836003)(105586002)(6486002)(6506006)(3280700002)(86362001)(66066001)(14454004)(966005)(6512007)(33656002)(5660300001)(106356001)(6306002)(478600001)(8936002)(101416001)(83716003)(81156014)(8676002)(81166006)(3660700001)(316002)(305945005)(7736002)(2501003)(2900100001)(25786009)(2906002)(77096006)(4326008)(53936002)(189998001)(97736004)(68736007)(36756003)(110136005)(54356999)(450100002)(6436002)(50986999)(99286004)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2456; 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="utf-8" Content-ID: <3562117194DFEC4E8CB6610E55331911@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 7037cc73-f6a4-41de-f7e0-08d536e5d820 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 04:58:34.1510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2456 Archived-At: Subject: [Ntp] Joint NTP/TICTOC virtual interim meeting (Tuesday, 12 December, 1700-1830 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, 29 Nov 2017 04:58:43 -0000 Rm9sa3MsDQoNCldlIHdpbGwgaGF2ZSBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9mIHRoZSBO VFAgYW5kIFRJQ1RPQyB3b3JraW5nIGdyb3VwcyBvbiBUdWVzZGF5LCAxMiBEZWNlbWJlciAyMDE3 LCBmcm9tIDE3MDAgdG8gMTgzMCBVVEMgKDEyOjAwIC0gMTozMCBwbSBFU1QpKS4gQSBkcmFmdCBh Z2VuZGEgd2lsbCBmb2xsb3cgc2hvcnRseS4gVGhlIGNhbGwgaW4gZGV0YWlscyBhcmUgcHJvdmlk ZWQgYmVsb3cuIA0KDQpUaGFua3MsDQpLYXJlbg0KDQpab29tIGRldGFpbHM6IA0KVG9waWM6IE5U UC9USUNUT0MgdmlydHVhbCBpbnRlcmltIA0KVGltZTogRGVjIDEyLCAyMDE3IDEyOjAwIFBNIEVh c3Rlcm4gVGltZSAoVVMgYW5kIENhbmFkYSkNCg0KSm9pbiBmcm9tIFBDLCBNYWMsIExpbnV4LCBp T1Mgb3IgQW5kcm9pZDogaHR0cHM6Ly9pc29jLnpvb20udXMvai80NDM5NzA2MTYNCg0KT3IgaVBo b25lIG9uZS10YXAgOg0KICAgIFVTOiArMTY0NjU1ODg2NTYsLDQ0Mzk3MDYxNiMgIG9yICsxNjY5 OTAwNjgzMywsNDQzOTcwNjE2IyANCk9yIFRlbGVwaG9uZToNCiAgICBEaWFsKGZvciBoaWdoZXIg cXVhbGl0eSwgZGlhbCBhIG51bWJlciBiYXNlZCBvbiB5b3VyIGN1cnJlbnQgbG9jYXRpb24p77ya DQogICAgICAgIFVTOiArMSA2NDYgNTU4IDg2NTYgIG9yICsxIDY2OSA5MDAgNjgzMyANCiAgICBN ZWV0aW5nIElEOiA0NDMgOTcwIDYxNg0KICAgIEludGVybmF0aW9uYWwgbnVtYmVycyBhdmFpbGFi bGU6IGh0dHBzOi8vaXNvYy56b29tLnVzL3pvb21jb25mZXJlbmNlP209aVZ1YTE2cDAwN2ZnbVlp QW9qNzJXd3FKY3V2UUZaRE8NCg0KT3IgYW4gSC4zMjMvU0lQIHJvb20gc3lzdGVtOg0KICAgIEgu MzIzOiANCiAgICAgICAgMTYyLjI1NS4zNy4xMSAoVVMgV2VzdCkNCiAgICAgICAgMTYyLjI1NS4z Ni4xMSAoVVMgRWFzdCkNCiAgICAgICAgMjIxLjEyMi44OC4xOTUgKENoaW5hKQ0KICAgICAgICAx MTUuMTE0LjEzMS43IChJbmRpYSkNCiAgICAgICAgMjEzLjE5LjE0NC4xMTAgKEVNRUEpDQogICAg ICAgIDIwMi4xNzcuMjA3LjE1OCAoQXVzdHJhbGlhKQ0KICAgICAgICAyMDkuOS4yMTEuMTEwIChI b25nIEtvbmcpDQogICAgICAgIDY0LjIxMS4xNDQuMTYwIChCcmF6aWwpDQogICAgICAgIDY5LjE3 NC41Ny4xNjAgKENhbmFkYSkNCiAgICBNZWV0aW5nIElEOiA0NDMgOTcwIDYxNg0KDQogICAgU0lQ OiA0NDM5NzA2MTZAem9vbWNyYy5jb20NCg0KDQo= From nobody Wed Nov 29 11:37:02 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 5C410126C22; Wed, 29 Nov 2017 11:36:47 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151198420724.7940.7296994125427843144@ietfa.amsl.com> Date: Wed, 29 Nov 2017 11:36:47 -0800 Archived-At: Subject: [Ntp] Network Time Protocol (ntp) WG Virtual Meeting: 2017-12-12 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: Wed, 29 Nov 2017 19:36:47 -0000 The Network Time Protocol (ntp) Working Group will hold a virtual interim meeting on 2017-12-12 from 12:00 to 13:30 America/New_York. Folks, We will have a virtual interim meeting of the NTP and TICTOC working groups on Tuesday, 12 December 2017, from 1700 to 1830 UTC (12:00 - 1:30 pm EST)). A draft agenda will follow shortly. The call in details are provided below. Thanks, Karen Zoom details: Topic: NTP/TICTOC virtual interim Time: Dec 12, 2017 12:00 PM Eastern Time (US and Canada) Join from PC, Mac, Linux, iOS or Android: https://isoc.zoom.us/j/443970616 Or iPhone one-tap : US: +16465588656,,443970616# or +16699006833,,443970616# 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: 443 970 616 International numbers available: https://isoc.zoom.us/zoomconference?m=iVua16p007fgmYiAoj72WwqJcuvQFZDO 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) 69.174.57.160 (Canada) Meeting ID: 443 970 616 SIP: 443970616@zoomcrc.com From nobody Wed Nov 29 23:58:27 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 571F51279E5; Wed, 29 Nov 2017 23:58:20 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151202870031.4752.5380814850173561280@ietfa.amsl.com> Date: Wed, 29 Nov 2017 23:58:20 -0800 Archived-At: Subject: [Ntp] I-D Action: draft-stenn-ntp-suggest-refid-02.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 07:58:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Network Time Protocol Suggest REFID Extension Field Author : Harlan Stenn Filename : draft-stenn-ntp-suggest-refid-02.txt Pages : 6 Date : 2017-11-29 Abstract: NTP has been widely used through several revisions, with the latest being RFC 5905 [RFC5905]. A core component of the protocol and the algorithms is the Reference ID, or REFID, which is used to identify the source of time used for synchronization. Traditionally, when the source of time was another system the REFID was the IPv4 address of that other system. The purpose of the REFID is to prevent a one- degree timing loop, where if A has several timing sources that include B, if B decides to get its time from A we don't want A then deciding to get its time from B. The REFID is considered to be "public data" and is a vital core-component of the base NTP packet. If a system's REFID is the IPv4 address of its system peer, an attacker can try to use that information to send spoofed time packets to either or both the target or the target's server, attempting to cause a disruption in time service. This proposal is a backward- compatible way for a time source to tell its peers or clients "If you use me as your system peer, use this nonce as your REFID." This nonce SHOULD be untraceable to the original system, and if it is used as the REFID this type of attack is prevented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-stenn-ntp-suggest-refid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-stenn-ntp-suggest-refid-02 https://datatracker.ietf.org/doc/html/draft-stenn-ntp-suggest-refid-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-stenn-ntp-suggest-refid-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 30 04:11:34 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 B40081293E9; Thu, 30 Nov 2017 04:11:26 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151204388671.4764.11514463356391498949@ietfa.amsl.com> Date: Thu, 30 Nov 2017 04:11:26 -0800 Archived-At: Subject: [Ntp] I-D Action: draft-stenn-ntp-i-do-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: Thu, 30 Nov 2017 12:11:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Network Time Protocol I-Do Extension Field Author : Harlan Stenn Filename : draft-stenn-ntp-i-do-03.txt Pages : 6 Date : 2017-11-30 Abstract: The first implementation of NTPv4 was released in 2003. NTPv4 is defined by RFC 5905 [RFC5905]. It contains a public-key security protocol, Autokey, which is defined by RFC 5906 [RFC5906]. Until very recently, Autokey has been the only defined "user" of NTP packet Extension Fields. New proposals for extension fields are being written and there is currently no convenient way to learn if a remote instance of NTP supports any extension fields or not. This proposal contains a method to tell a remote instance of NTP what we (are willing to admit we) support, and ask what they (are willing to admit they) support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-stenn-ntp-i-do/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-stenn-ntp-i-do-03 https://datatracker.ietf.org/doc/html/draft-stenn-ntp-i-do-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-stenn-ntp-i-do-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 Thu Nov 30 05:01:03 2017 Return-Path: X-Original-To: ntp@ietf.org Delivered-To: ntp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 994491200F3; Thu, 30 Nov 2017 05:01:01 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151204686157.4910.3701116176839579963@ietfa.amsl.com> Date: Thu, 30 Nov 2017 05:01:01 -0800 Archived-At: Subject: [Ntp] I-D Action: draft-ietf-ntp-refid-updates-01.txt X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 13:01:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol WG of the IETF. Title : Network Time Protocol REFID Updates Authors : Harlan Stenn Sharon Goldberg Filename : draft-ietf-ntp-refid-updates-01.txt Pages : 10 Date : 2017-11-30 Abstract: RFC 5905 [RFC5905], section 7.3, "Packet Header Variables", defines the value of the REFID, the system peer for the responding host. In the past, for IPv4 associations the IPv4 address is used, and for IPv6 associations the first four octets of the MD5 hash of the IPv6 are used. There are at least three shortcomings to this approach, and this proposal will address the three so noted. One is that knowledge of the system peer is "abusable" information and should not be generally available. The second is that the four octet hash of the IPv6 address looks very much like an IPv4 address, and this is confusing. The third is that a growing number of low-stratum servers want to offer leap-smeared time to their clients, and there is no obvious way to know if a server is offering accurate time or leap- smeared time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-refid-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-refid-updates-01 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-refid-updates-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-refid-updates-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/