[Dots] Warren Kumari's Discuss on draft-ietf-dots-telemetry-20: (with DISCUSS)

Warren Kumari via Datatracker <noreply@ietf.org> Wed, 02 February 2022 17:00 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D79D93A15DE; Wed, 2 Feb 2022 09:00:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-telemetry@ietf.org, dots-chairs@ietf.org, dots@ietf.org, valery@smyslov.net, valery@smyslov.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <164382121385.21407.6415201995737053293@ietfa.amsl.com>
Date: Wed, 02 Feb 2022 09:00:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Wuo7E0aZXlGca8sH7thRTSdE3dk>
Subject: [Dots] Warren Kumari's Discuss on draft-ietf-dots-telemetry-20: (with DISCUSS)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2022 17:00:14 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-dots-telemetry-20: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please note: This really is just a DISCUSSion - I'm happy to be educated /
wrong, but I do think that it is important enough that it gets addressed.

The 'unit-class' and 'unit' enumerations seems like they add a large amount of
complexity for (AFAICT) very little gain. Do you really need:
             "Packets per second (pps).";
             "Bits per Second (bps).";
             "Bytes per second (Bps).";
             "Kilo packets per second (kpps).";
             "Kilobits per second (kbps).";
             "Kilobytes per second (kBps).";
             "Mega packets per second (Mpps).";
             "Megabytes per second (MBps).";
             "Giga packets per second (Gpps).";
             "Gigabits per second (Gbps).";
             "Gigabytes per second (GBps).";
             "Tera packets per second (Tpps).";
             "Terabits per second (Tbps).";
             "Terabytes per second (TBps).";
             "Peta packets per second (Ppps).";
             "Petabits per second (Pbps).";
             "Petabytes per second (PBps).";
             "Exa packets per second (Epps).";
             "Exabits per second (Ebps).";
             "Exabytes per second (EBps).";
             "Zetta packets per second (Zpps).";
             "Zettabits per second (Zbps).";
             "Zettabytes per second (ZBps)."
when just Packets Per Second and Bits Per Second would work? Yes, you might
have to have a really large number in BPS, but that seems much much less likely
to lead to errors than having parsers have to deal with this. When a user
enters a number their glass would presumably allow them to use a more
convenient unit, but having it encoded and decoded into this seems needlessly
complex.

I did look through the document and list to try and find discussions on this
point - I'm happy to be pointed at a place where it was discussed and agreed.