[6lo] Roman Danyliw's No Objection on draft-ietf-6lo-fragment-recovery-12: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 18 February 2020 13:08 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 89758120047; Tue, 18 Feb 2020 05:08:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-fragment-recovery@ietf.org, Carles Gomez <carlesgo@entel.upc.edu>, 6lo-chairs@ietf.org, carlesgo@entel.upc.edu, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <158203129954.14101.12430232892469230181.idtracker@ietfa.amsl.com>
Date: Tue, 18 Feb 2020 05:08:19 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/GHLkrZj72UVMUb1sf8htmufU958>
Subject: [6lo] Roman Danyliw's No Objection on draft-ietf-6lo-fragment-recovery-12: (with 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: Tue, 18 Feb 2020 13:08:20 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-6lo-fragment-recovery-12: No Objection

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-fragment-recovery/



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

Thank you for this easy to read document.

** Section 5.1.  Per “There is no requirement on the receiver to check for
contiguity of the received fragments, and the sender MUST ensure that when all
fragments are acknowledged, then the datagram is fully received.”, the second
clause doesn’t parse for me.  What must the sender ensure when all of the
fragments are acknowledged?

** Section 5.1.  Fragment_Size.  If this is a 10-bit unsigned integer and the
unit is an octet, shouldn’t fragments up to 1024-1 bytes be possible (not 512)?

** Editorial

-- Section 5.2.  Editorial.
s/A NULL bitmap that indicates that the …/
A NULL bitmap indicates that the …/
s/A FULL bitmap that indicates that the …/
A FULL bitmap indicates that the …/

-- Section 6.1.  Recommend replacing colloquial language – “It inherits … using
a timer to clean the VRB when the traffic _dries up_”

-- Section 10.  Typo. s/ot this/to this/