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

Barry Leiba <barryleiba@computer.org> Fri, 07 February 2020 15:22 UTC

Return-Path: <barryleiba@gmail.com>
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 893671208C3; Fri, 7 Feb 2020 07:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8V6U-ZsVi29; Fri, 7 Feb 2020 07:22:48 -0800 (PST)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 506361208C0; Fri, 7 Feb 2020 07:22:48 -0800 (PST)
Received: by mail-io1-f47.google.com 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; d=1e100.net; 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: <158105542542.16105.11730811173407473905.idtracker@ietfa.amsl.com> <MN2PR11MB35651E4392668D57EE8CBD78D81C0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35651E4392668D57EE8CBD78D81C0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 7 Feb 2020 10:22:36 -0500
Message-ID: <CALaySJKxZsWbk3bp_u4U4HazSrRFQc2idDi1jZAjf5p2AOrxcg@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-6lo-minimal-fragment@ietf.org" <draft-ietf-6lo-minimal-fragment@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"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/f6c6c9JhTmOJNOfJODXAgNsTQ3E>
Subject: Re: [6lo] Barry Leiba's No Objection on draft-ietf-6lo-minimal-fragment-10: (with 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, 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.

-- 
Barry