[TICTOC] Benjamin Kaduk's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Thu, 11 October 2018 13:51 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: tictoc@ietf.org
Delivered-To: tictoc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F12130E72; Thu, 11 Oct 2018 06:51:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tictoc-1588v2-yang@ietf.org, Karen O'Donoghue <odonoghue@isoc.org>, tictoc-chairs@ietf.org, odonoghue@isoc.org, tictoc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.86.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153926586208.14803.13432042276042241561.idtracker@ietfa.amsl.com>
Date: Thu, 11 Oct 2018 06:51:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/HNA0Zvnz3v1S0IUzczx5hoQxJsE>
Subject: [TICTOC] Benjamin Kaduk's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Oct 2018 13:51:03 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-tictoc-1588v2-yang-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I appreciate that there has been some previous work in this area, but it seems that there are still many instances of bare integral types with no indication of what units are used to report a numerical value, whether larger or smaller priority values indicate a more preferred status, how the sign of an "offset" measurement should be interpreted, etc. This leaves the specification unimplementable in an interoperable way. A (possibly incomplete) list of such values includes: clock-class (is this really more like an enum than an int?) clock-accuracy (ditto?) offset-scaled-log-variance priority1 (are small or large values more-preferred?) priority2 (ditto) offset-from-master (interpretation of sign bit) observed-parent-offset-scaled-log-variance observed-parent-clock-phase-change-rate grandmaster-priority1 grandmaster-priority2 current-utc-offset (sign bit) time-source (is this more like an enum?) log-min-delay-req-interval (units have to be scaled out before log operation) log-announce-intervale (ditto) log-sync-interval (ditto) log-min-pdelay-req-interval (ditto, two different nodes) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 o When the IEEE 1588 standard is revised (e.g. the IEEE 1588 revision in progress at the time of writing this document), it will add some new optional features to its data sets. The YANG module of this document MAY be revised and extended to support these new features. Moreover, the YANG "revision" SHOULD be used to indicate changes to the YANG module under such a circumstance. It's not clear that a 2119 SHOULD is best here; I would have expected either an 8174 "should" or a 2119 "MUST". Section 3 time-interval-type says "units of nanoseconds and multiplied by 2^16". I assume I'm interperting that wrong, since there doesn't seem to be much point in claiming a precision in yoctoseconds. Most "log" values specify the "base-two logarithm", but offsetScaledLogVariance has a much more vague description. Lacking access to IEEE 1588-2008, I can't tell if it is possible to be more precise for describing this field. (Also, you can only take the log of a dimensionless quantity, so the input units need to be specified, per my Discuss.) > slave-only clock So we had this long discussion on ietf@ietf.org about potentially offensive terminology, including "master"/"slave". We have leap59/leap61; might we need a leap62? Section 4 (I guess you don't need to talk about sensitive ro nodes when all the nodes are under the sensitive rw nodes already mentioned.)
- [TICTOC] Benjamin Kaduk's Discuss on draft-ietf-t… Benjamin Kaduk
- Re: [TICTOC] Benjamin Kaduk's Discuss on draft-ie… Jiangyuanlong
- Re: [TICTOC] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [TICTOC] Benjamin Kaduk's Discuss on draft-ie… Jiangyuanlong
- Re: [TICTOC] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk