Re: [6lo] Barry Leiba's No Objection on draft-ietf-6lo-minimal-fragment-10: (with COMMENT)

Barry Leiba <> Fri, 07 February 2020 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 893671208C3; Fri, 7 Feb 2020 07:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R8V6U-ZsVi29; Fri, 7 Feb 2020 07:22:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 506361208C0; Fri, 7 Feb 2020 07:22:48 -0800 (PST)
Received: by with SMTP id k24so2587520ioc.4; Fri, 07 Feb 2020 07:22:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bxL3S4XzzLq8DMajCAOoIq52fV3RoGdVxMBIWfV7Wfg=; b=kmTeiMPRheM9X4FrkYUWGnXhdbyI4Ely3O4gZOSZbBaiBXukaHiexW2wI6Qn4AxLPT B7rI92My/5q+2WkxJEUo5I3gbCzQj9hcOp27JXarODWIZwXyBwNX/jEPYYf+G64MiDf+ 6MutqezVkhUGAgWesBQr+NTLNIN0IqPGtzZDvgsEOvllbf2tMLr8qAqfWyiChf41lmic T8YE7HABAzzBR7SJ6VYAQ59v5+WaYfy10dpdiFFkJfUJkiX7R2LFS1ux1Wmig0NdKNbF chkWkJ2A9Id0zgXH3LDGQhMMEMkkZh0O3mzhowmtTiwJqW9tEjbzPEtN2pwnJbmK9lUR P4yA==
X-Gm-Message-State: APjAAAWyzvlKHRUf7PipUwhpmDK2HdtYSQWHtYjuvSuPNVrdVCg23zUX /gwfTp4yTmAZh+NAmpWpKfVRyN4ZW5D9Kc/f8jc=
X-Google-Smtp-Source: APXvYqyv9eejZ8oxMX8n3z6A8DmrKwf1NrEsTT/StvIJzNjfiBBZc1TT5/aJxF8KyWS6eG9J9NvjOmT7FRAvwfKGzKc=
X-Received: by 2002:a5d:9a85:: with SMTP id c5mr3550860iom.266.1581088967438; Fri, 07 Feb 2020 07:22:47 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Fri, 7 Feb 2020 10:22:36 -0500
Message-ID: <>
To: "Pascal Thubert (pthubert)" <>
Cc: The IESG <>, "" <>, Carles Gomez <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [6lo] Barry Leiba's No Objection on draft-ietf-6lo-minimal-fragment-10: (with COMMENT)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2020 15:22:50 -0000

Hi, Pascal, and thanks for the quick reply and for addressing my
comments.  For anything I don't mention further below, all is OK.

> > I think this makes FRAG-ILE a normative reference (necessary security issues).
> > It would also be useful to have a “see Section 7” forward pointer here, so it’s
> > clear that the specific issues are discussed later in this document.
> It was never published and never will be, so procedure-wise that's calling for trouble.
> The paragraph now looks like:
> "
>    "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
>    threats that are linked to using IP fragmentation.  The 6LoWPAN
>    fragmentation takes place underneath, but some issues described there
>    may still apply to 6LoWPAN fragments (as discussed in further details
>    in Section 7).
> "
> Works?

Ah, OK, I didn't realize it wasn't meant to be published formally.
Yes, I think this works, because section 7 has enough detail that it
can stand as its own normative reference.  Thanks.

> > I think this makes 4919 a normative reference (necessary terminology and
> > concepts).
> A downref but OK, I'll trust an IESG review on this : )

Yes, not a problem: downrefs are now common, unremarkable, and not
problematic, as we often publish terminology and architecture/concepts
documents as Informational.

>>    This specification uses the following terms:
>> I would say it “defines” these terms, no?
> Not really, they appear in RFC 4944, but ok

OK, no... I hadn't realized (and didn't check) that they were defined
in 4944.  Sorry; leave as is.

> Which gives:
> "
>    6LoWPAN endpoints:  The 6LoWPAN endpoints are the first and last
>       nodes in an unbroken string of 6LoWPAN nodes.  They are in charge
>       of generating or expanding a 6LoWPAN header from/to a full IPv6
>       packet.  They are also the points where the fragmentation and
>       reassembly operations take place.
> "

I like it.

> > Should this be “limitations”, rather than “limits”?  It seems so.  Also
> > throughout Section 6.
> And later, changed to caveats on occasion, see:

Yes; "caveats" works too; thanks.

> > — Section 6 —
> > (Change “limits” to “limitations” throughout the section.) Doesn’t this
> > section need LWIG-VRB to be a normative reference?
> I do not think so. The whole idea in this section was that the text would be self-describing.
> People are free to dig in the LWIG spec but that is not needed to understand this text.

OK; that makes sense.