Re: [6lo] Warren Kumari's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

Warren Kumari <warren@kumari.net> Fri, 06 March 2020 20:23 UTC

Return-Path: <warren@kumari.net>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10983A09B5 for <6lo@ietfa.amsl.com>; Fri, 6 Mar 2020 12:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9i-YRgZkO9W for <6lo@ietfa.amsl.com>; Fri, 6 Mar 2020 12:23:46 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DA63A09B4 for <6lo@ietf.org>; Fri, 6 Mar 2020 12:23:45 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id z9so2950165lfa.2 for <6lo@ietf.org>; Fri, 06 Mar 2020 12:23:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NGoDFH/Lfw4erEfnUetVA44yakr+8rpcEP3RQqEQrfg=; b=ZjTiNOXGAgySj+qiQKaEZBNpDWVIVEJTZg3byYJZG1t5Ysi6RrcXJAPuGiVioxtzAy kBg44Aof7bXGTHO37rczJA2qROnu+Jxn3mq9rj7XlS7gCQJayEjEgDwyM7NvMG/mpGAi KCCHNw/C2ZElzMLVQ0oXhvcluU2R0uNzCSXJRNZMLdVx3HBGtSQP78Ljfvap9GCsp+0P j4uaPy3zNWCj6QPftvSKxD+6RdDgfNtB10RZvZ3hcxBK7B2u1eIN/vTFHpJ+7rXuwLZx zpmql/jIRyzzZHEaqFu6BUhsCjNjJWx61Xy+YiU9zm9oycjpzf+f9Bx3eEomsoQrF2uC ZMOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NGoDFH/Lfw4erEfnUetVA44yakr+8rpcEP3RQqEQrfg=; b=MkMK9kAUKw2d488v3ALTA9Lt/zxLvffde3OQ/xq5hQPt87PpdeYj33oolsihMXnSEo mVjU/BOnR0PUvXA2n8WRfbJ9HxSEV6ekaoTQQ/6H25IMPSV0qcto5OwxeX54K3iOK8j0 rcZufhbiZexa8lvFXk7KYbuOB0JiG3JsbziAzorUrMl+LAwVxSZisjwAmYLIsdSz1dYP f4py7b77VqaSKAgNUgvIvO/rRiT9T8+QOP7o820ffTvqMMKPJWWV5zi7LqsvYsa1ygdK 7iTi6f+MbryGWrYDc/CIk9fB45OXUgRhwbjYmQIBnGV2BIkmJyvlwuy377phjGia6UuT qhYA==
X-Gm-Message-State: ANhLgQ2Kd6JPsnqriVwuFQp1KdeLkmv26Vb2kss3yFkAB6MovPRbFUpx FkfMs15/f9b1G/WevnYNA+i+GnQHCbMKzJ8E2PdkNA==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vt+h2w5QZWcH6BC/PrWgYjfrtE5xFU0+bwxDIQS?= =?utf-8?q?UUBdjx40sjGJRiLM2DSGtBKAHoQtHbKz7+/huOwqr4nea78=3D?=
X-Received: by 2002:ac2:5090:: with SMTP id f16mr1426920lfm.200.1583526223308; Fri, 06 Mar 2020 12:23:43 -0800 (PST)
MIME-Version: 1.0
References: <158214894500.17738.11622768395191956565.idtracker@ietfa.amsl.com> =?utf-8?q?=3CMN2PR11MB356554CBB1689BFC50363167D8E30=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CMN2PR11MB356554CBB1689BFC50363167D8E30=40MN2PR11MB?= =?utf-8?q?3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
From: Warren Kumari <warren@kumari.net>
Date: Fri, 6 Mar 2020 15:23:06 -0500
Message-ID: <CAHw9_iKNpd=XxWTOZ__LpV-Cd3ZWHmEEbpLTTJCPNf3zSGD4Dw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/3KPobADC7dWei1Mf9b5EIzyDe5g>
Subject: Re: [6lo] Warren Kumari's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 06 Mar 2020 20:23:48 -0000

Awesome. thank you, I have cleared my discuss position,
W

On Fri, Mar 6, 2020 at 1:57 PM Pascal Thubert (pthubert)
<pthubert@cisco.com> wrote:
>
> Hello Warren
>
> Many thanks for your review!
>
> Please find the proposed changes discussed below in https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14
>
> Let's see below:
>
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > [ Be ye not afraid - this should be easy to address.]
> > "datagram_size: The size of the datagram in its Compressed Form before it is
> > fragmented. The datagram_size is expressed in a unit that depends on the
> > MAC layer technology, by default a byte." and: "Fragment_Size:  10-bit
> > unsigned integer; the size of this fragment in a unit that depends on the MAC
> > layer technology.  Unless overridden by a more specific specification, that
> > unit is the octet, which allows fragments up to 1024 bytes."
> >
> > I spent quite a while going though the document, looking at the 13 places
> > where you use 'byte' and 3 where you use 'octet', trying to figure out if there
> > is a reason that different terms are used. Normally I'd just say "meh, these
> > are synonyms" and ignore it, but in this particular specification (because of
> > the "by default" / "Unless overridden") I think it is actually important.... Can
> > you standardize on one of the other, or provide more explanatory text if
> > there is a reason?
>
> Standardized to Byte, per Carsten's recommendation. As a Frenchman I preferred octet : )
> Note that the definition is now removed from this document and inherited from I-D.ietf-6lo-minimal-fragment per Benjamin's review.
>
> The end of appendix A becomes:
> "
>
>    Mechanisms such as TCP or application-layer segmentation could be
>    used to support end-to-end reliable transport.  One option to support
>    bulk data transfer over a frame-size-constrained LLN is to set the
>    Maximum Segment Size to fit within the link maximum frame size.
>    Doing so, however, can add significant header overhead to each
>    802.15.4 frame and cause extraneous acknowledgements across the LLN.
> "
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you for a useful and interesting read -- I really enjoyed this document.
> >
> > I do also support Benjamins "I think we should be more clear about whether
> > a "FULL bitmap" always has 32 bits set to one, or if "merely" having as many
> > bits as the sender sent fragments set to one also counts as "FULL". "
> > comment, and had something very similar drafted...
> >
>
> Yes, I addressed this in Benjamin's review. But I did not really find the place that triggered the doubt.
> There is new text now, I hope that fixes it. There is also a definition of FULL and NULL bitmaps:
>
> "
>    NULL bitmap:  Refers to a bitmap with all bits set to zero.
>
>    FULL bitmap:  Refers to a bitmap with all bits set to one.
>
> "
> I hope it is clear enough, but happy to reword if needed.
>
> Many thanks again for your review : )
>
> Pascal



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf