Re: [Ntp] WG Call for Adoption: draft-aanchal-time-implementation-guidance (On Implementing Time)

Joachim Fabini <joachim.fabini@tuwien.ac.at> Wed, 07 November 2018 15:38 UTC

Return-Path: <joachim.fabini@tuwien.ac.at>
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 D3F5E130DC3 for <ntp@ietfa.amsl.com>; Wed, 7 Nov 2018 07:38:57 -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] 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 WWAaI6jjlmDt for <ntp@ietfa.amsl.com>; Wed, 7 Nov 2018 07:38:55 -0800 (PST)
Received: from mail.nt.tuwien.ac.at (mail.nt.tuwien.ac.at [128.131.67.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C464A127B92 for <ntp@ietf.org>; Wed, 7 Nov 2018 07:38:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.nt.tuwien.ac.at (Postfix) with ESMTP id 0952B54EF2B4; Wed, 7 Nov 2018 16:38:52 +0100 (CET)
Received: from mail.nt.tuwien.ac.at ([127.0.0.1]) by localhost (mail.nt.tuwien.ac.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1FAOBEyAk9I; Wed, 7 Nov 2018 16:38:50 +0100 (CET)
Received: from [128.131.67.239] (jason.nt.tuwien.ac.at [128.131.67.239]) by mail.nt.tuwien.ac.at (Postfix) with ESMTPSA id 4082454EF2A7; Wed, 7 Nov 2018 16:38:50 +0100 (CET)
Reply-To: joachim.fabini@tuwien.ac.at
To: Karen O'Donoghue <odonoghue@isoc.org>, "ntp@ietf.org" <ntp@ietf.org>
References: <2049ADDC-A37C-48D3-BCC3-4D5916CA87C2@isoc.org>
From: Joachim Fabini <joachim.fabini@tuwien.ac.at>
Openpgp: preference=signencrypt
Autocrypt: addr=joachim.fabini@tuwien.ac.at; prefer-encrypt=mutual; keydata= xsBNBFN/ZBIBCADMmi08FdbN6Gcq8fr/HFOT0Rhlfez5bpWc0vppC2NF186TDM07H9r85MSy 3JKk2ghUimSB4nRj2FZgA9KdKCgr4nVLdRpMGAvfEp5q9CNpC3Oc3KEs0tknbOZjPrzK9aI1 G1gLvyFxxluCvbxtp0b8oG9HC5gNLeTXTH4KvdVXGu9fjsw+PP2/Sx0Fvk8BR3vGZ/56J/EL qer55TK436pc6br1VW/KzwFgWFDGBIUXEGY8n2Iic+ASp5CVyYdsHi8XLB00fizttWE224Ch mAMolFw0kr4ykT3bzKVoFp4V6noqL1L1E6W+yY8YgkjU7YL0WSKAm0hoyGwxDYSVr0wdABEB AAHNLEpvYWNoaW0gRmFiaW5pIDxKb2FjaGltLkZhYmluaUB0dXdpZW4uYWMuYXQ+wsB/BBMB AgApBQJTf2QSAhsjBQkJZgGABwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQoI/cE+9G p9KsmwgAxyTqWyYcpErMFZUmMc4fZmZJGbCOXInfpdhGgB1qCjlcuamzM1Q9s7IGQxzGTW4J YOV689DN/Bg2sWRL6Wy1qutKL5lcUhu4r8hxWlFBqHLf9QLDOwEfk7PE8oX8ARtzCh6Pvc6I Y9OxyMN7FbIUcJnRIrljmG78ve1fGz8kxbw/jPkkSZJOvsTgMVQYpZMAwP9NjLDJjIRs09ov hWpgXkolqQQDLRWRVsRB41zwRAZyr85g7chxOD1BWxf3eV/9nEyvZN2cMAd4Hz7PNUpgsuF2 5KXPE0J/l+EVWQMAo62kBS9TgC+ikjEetCxwIKhnU208nfOrTDl4etoN0rzE687ATQRTf2QS AQgA3jZtzwyjaoMRyd02Qy881r8AjXTZrQlGKmfzEMuFIfkkor3Rui0jP6Cr1GgI4Pa2nDSg 0/V1R0TOoFiEjaxXjxKBo6jRoqGXD929zlNM07ueupfdR1mKoN6Hr+1AalmIf9POOqc7DpVn K+YWiM45gbfoAxA/C09vZQX4u1SYrQZEemOT/Z1KpFI3dICKfzuaVw83CVnmNSEqSegWetP6 2ksYgwFYN7UuRr8NEpckMvzn5HrkYs2TE+TMpcaB3JDC3dklADfJvytJNyAGqb3G2BeBWgIv KXypZbyd/4Qw6hTjNYy/WpgUCPPsMtzSatjEgowmHjZbdLOR7FjNXkY6KwARAQABwsBlBBgB AgAPBQJTf2QSAhsMBQkJZgGAAAoJEKCP3BPvRqfS91QIALqzvaTpEefODaiKfVeCv4dwxZGB VhHzDiXrDGZCGJd982pasZeZnJbQT/bmt0HSyTKgBjwpxzV5FBKT7WRRmuLqdul/2n1wAcxk b0t7FewpOmOIi5sEFuOVx6jbY7dzpiOyAnaaXsYt76ydHmWUxe22ii2QI9hI7PxGvTxHIa8K N+vt89bkW7eXmQfEDpRjjhM4nXjmNUYtefmgwnX3L6geXP/R5bf1ELDRllOR2+cjz47kZbCR E/5O5v1evN1QlA+wxnikwRyrTyXzKl3w88rNsSEZYDokDGyWdLGtgVuyjkYX1XhBGKq0DfYK uTh5FsArNOX7/MdKWYjVXlwf5Fo=
Message-ID: <ed17b108-36a8-46ae-b0f1-a71f243e0a6c@tuwien.ac.at>
Date: Wed, 07 Nov 2018 16:38:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <2049ADDC-A37C-48D3-BCC3-4D5916CA87C2@isoc.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/_7LwKz853mTyLLgJHT4kLoPm0Kc>
Subject: Re: [Ntp] WG Call for Adoption: draft-aanchal-time-implementation-guidance (On Implementing Time)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 15:38:58 -0000

Hi Karen, all,

I've read the draft and initially planned to express my support for
adoption (still do it, but conditionally). Some suggestions in my
supporting email identified a structural problem and it turned out that
splitting the implementation-guidance draft into two distinct documents
brings benefits.  Please find my comments and proposal below, feel free
to comment.

Imo the draft mixes up two important aspects: (1) Time terminology (that
is independent of operating systems, protocols, hardware) and (2) time
implementation guidance (likely to change with time).

1. Terminology. To the best of my knowledge there is no ultimate and
comprehensive (IETF) protocol-independent reference of time-related
terms and concepts. Such a document is (imo) needed and can be a truly
valuable contribution. The challenge is to define the vocabulary in a
protocol-independent way. But merging sections 3 and 4 of
time-implementation-guidance with terms and definitions within other
RFCs may yield a good compromise with reasonable effort.
In particular section 10 of RFC2330,
https://tools.ietf.org/html/rfc2330#section-10.1  defines already
essential clock-related concepts on top of which the IPPM (IP
Performance Metrics Framework) is built. Examples include accurate
clocks, precise clocks, clock resolution, skew, drift, etc. (*) - terms
that the time implementation guide will need for sure, too.

2. Implementation Guidance
Outsourcing the terms and definitions part to an own document permits
the implementation guide to focus on the actual challenges.

Summarizing, the definitions in the terminology section of the
implementation draft are essential for past, present and future
time-related discussions and documents. Before realizing this structural
issue I planned to suggest adding the clock-related concepts of RFC2330
to the implementation-guide draft's definitions section.

But now I truly believe that an own time terminology draft is more helpful.

So my proposal is to adopt the time-implementation-guidance draft but
shift its protocol-independent definitions to a new time terms and
definitions draft. If needed I'm volunteering to contribute to the latter.

thanks,
Joachim

(*) A valid question is why the RFC2330 clock definitions are defined as
part of the IPPM framework and not in a larger context. Anyhow, they are
useful and have stood the test of time...


On 11/6/18 10:10 PM, Karen O'Donoghue wrote:
> Folks,
> 
> As per the discussion at IETF 103, this email starts a WG Call for Adoption for: 
> 
> On Implementing Time
> https://datatracker.ietf.org/doc/draft-aanchal-time-implementation-guidance/
> 
> Please review the document and comment on the mailing list regarding the adoption of this document as a working group document. Note this means that we as a working group plan to review and comment on this work as it progresses. 
> 
> Thank you!
> Karen and Dieter
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>