[6lo] Alexey Melnikov's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

Alexey Melnikov via Datatracker <noreply@ietf.org> Wed, 15 May 2019 12:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 057C61200BA; Wed, 15 May 2019 05:59:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-deadline-time@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>, Shwetha Bhandari <shwethab@cisco.com>, 6lo-chairs@ietf.org, shwethab@cisco.com, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <155792519001.17589.14379773618187611342.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 05:59:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Nb6Th4ip6QsJSXuQssVSt6GcVJQ>
Subject: [6lo] Alexey Melnikov's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 12:59:50 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-6lo-deadline-time-04: 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-6lo-deadline-time/



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

I have a few small points (one is confusing enough to warrant a quick
discussion), but they affect clarity of the specification:

In Section 5:

   o  OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer,
      encoding the length of the field in hex digits.  If OTL == 0, the
      OTD field is not present.  The value of OTL MUST NOT exceed the
      value of DTL plus one.

      *  For example, DTL = 0b0000 means the deadline time in the 6LoRHE
         is 1 hex digit (4 bits) long.

Ok, so 0b0000 ==> (0 + 1) * 4, means 4 bits.

          OTL = 0b111 means the
         origination time is 7 hex digits (28 bits) long.

Is my math wrong or is your example wrong?

0b111 == 7. So (7 + 1) * 4 would be 32 bits.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Section 4:

   There are multiple ways that a packet can be delayed, including
   queuing delay, MAC layer contention delay, serialization delay, and
   propagation delays.  Sometimes there are processing delays as well.
   For the purpose of determining whether or not the deadline has
   already passed, these various delays are not distinguished.

Not distinguished from what? Do you mean "not counted"?

In Section 5:

   o  Binary Pt (6 bits) : If zero, the number of bits of the integer
      part the DT is equal to the number of bits of the fractional part
      of the DT.  if nonzero, the Binary Pt is a signed integer
      determining the position of the binary point within the value for
      the DT.

      *  If BinaryPt value is positive, then the number of bits for the
         integer part of the DT is increased by the value of BinaryPt,
         and the number of bits for the fractional part of the DT is
         correspondingly reduced.  This increases the range of DT.
      *  If BinaryPt value is negative, then the number of bits for the
         integer part of the DT is decreased by the value of BinaryPt,
         and the number of bits for the fractional part of the DT is
         correspondingly increased.  This increases the precision of the
         fractional seconds part of DT.

It would be good if you specified how negative values are represented (Ok,
maybe it is obvious) and the range for positive and negative values.