[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.
- [6lo] Alexey Melnikov's Discuss on draft-ietf-6lo… Alexey Melnikov via Datatracker
- Re: [6lo] Alexey Melnikov's Discuss on draft-ietf… Barry Leiba