Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 07 August 2019 01:48 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8743D120045; Tue, 6 Aug 2019 18:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3PdVJVjy66oB; Tue, 6 Aug 2019 18:48:36 -0700 (PDT)
Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 2A06B12000E; Tue, 6 Aug 2019 18:48:36 -0700 (PDT)
Received: by mail-pf1-x442.google.com with SMTP id t16so42486501pfe.11; Tue, 06 Aug 2019 18:48:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bmvwsbJY8L4i23HCW010108Bmg5BooP7tTPZgg0LQVA=; b=N5ZqdfYB8rj6V7MssADSgxuTOPNcadm9A3F43KjqoJQw6+tnTcUlmBLMP3hYV6TgFs gMGxNKkvf5EDn5Gijwd4C8sw8T0eREciz4PkvO7aHpDE4ATEE2kR3xoPN94CF091jPP2 z7hsQ7Yu+VFo3jQd6qoZ7tOdw45i7i7dKMi5+O2JqrhvQ3sYvrNG+wt/3wDIrf1dXYy5 g3VfW1xLHb7ff97pA8jmtxsL3o6RGaAQB6m0QfcY6XntElfRwVVSFtQOIB3xRcP/Z7bk AZG32Ns7M6YZnGdqTkqC6Cr8eM5qRRe122nAXQcWjqe2nyVT0xT3kGVpOpfkYQ4QiRr2 h3Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bmvwsbJY8L4i23HCW010108Bmg5BooP7tTPZgg0LQVA=; b=E9Whp9GzdoRKMI5zuDgytW0rb26WoYR87HKrz1ZOB2JgikP4Id5Ie7iDMesF715WZZ Gxdku898GSuyq89BVIYku6k8yn79WMgkBTZA87OdnEGpAT3JXt3lDBWsifEvLQPZepZU g0qinevTFsASZVtRIL4Bgsi4TAD5l8U5063VpRjSKNh69o2752AMltYcoSN3Na+W0FS/ brAV1j1xMQFUOuFQz3U7uVqK5sPuNxJ/HZvQPNWpWg/gYVltL8/R2hIe22SVd8IzBaj2 fwu6lUOqpqTTKmjkZ8fb9nZH+lvow7dcjboxEPbhwEdrQFpdohlDcC/DuQC67Ld6Upsl RkQg==
X-Gm-Message-State: APjAAAXCamKlVKvMrtSVU6aGNPAmHJtjkq29/yIK6qFi5XFZD1+jVdLH vfRmU1FOk6Yg2w+HHbNs1JRKW9lAz8g=
X-Google-Smtp-Source: APXvYqwG0xmrKov9bSinP3JQvglW2ybivlxJNOxq6dXT/+wZslYHSUQtYh62CrkmhBKNn9g6BFmj6w==
X-Received: by 2002:a63:3203:: with SMTP id y3mr5645206pgy.191.1565142515353; Tue, 06 Aug 2019 18:48:35 -0700 (PDT)
Received: from [130.216.36.184] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.184]) by smtp.gmail.com with ESMTPSA id d8sm82087933pgh.45.2019.08.06.18.48.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 18:48:34 -0700 (PDT)
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: draft-ietf-intarea-frag-fragile@ietf.org, int-area <int-area@ietf.org>, IESG <iesg@ietf.org>, intarea-chairs <intarea-chairs@ietf.org>
References: <156512344887.27340.5761295053779083959.idtracker@ietfa.amsl.com> <CALx6S35f9eH1SCFqWZoBtnFrqvdoXrhiPoPQTh2_w-LjwBzRSQ@mail.gmail.com> <6B2DA394-E11A-46C1-8A45-76D59BAF0783@cooperw.in> <974b24af-3f9f-95e3-87ec-d7a14eb9661d@gmail.com> <2b0e4ba4-ae38-7592-b5aa-b5d7201e5534@joelhalpern.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <39dd897f-d64b-551b-0bd5-5b9bc9a80fc8@gmail.com>
Date: Wed, 07 Aug 2019 13:48:30 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <2b0e4ba4-ae38-7592-b5aa-b5d7201e5534@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/4GLcpSaZ9dAt-Xvp9QoAgS7glPM>
Subject: Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 01:48:39 -0000

On 07-Aug-19 13:06, Joel M. Halpern wrote:
> Brian, I would think the text just above the paragraph Alissa quoted 
> would already cover what you ask for.  It begins:
>      Developers SHOULD NOT develop new protocols or applications that
>      rely on IP fragmentation.

Well yes, so the "unless" clause would fit right there. Saying both "SHOULD NOT" and "MAY" is redundant, which is why the word "unless" exists. So basically this is editorial (since Fernando is correct about the WG intention).

Although switching to "unless" doesn't exactly resolve Alissa's issue, I think it makes it clear that relying on fragmentation is a risky choice, whereas the MAY formulation makes it seem almost OK.

   Brian

> 
> Yours,
> Joel
> 
> On 8/6/2019 8:55 PM, Brian E Carpenter wrote:
>> On 07-Aug-19 12:11, Alissa Cooper wrote:
>>> Hi Tom,
>>>
>>>> On Aug 6, 2019, at 5:41 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>
>>>> On Tue, Aug 6, 2019 at 1:30 PM Alissa Cooper via Datatracker
>>>> <noreply@ietf.org> wrote:
>>>>>
>>>>> Alissa Cooper has entered the following ballot position for
>>>>> draft-ietf-intarea-frag-fragile-15: 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-intarea-frag-fragile/
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Thanks for writing this document.
>>>>>
>>>>> Section 6.1 says:
>>>>>
>>>>> "Developers MAY develop new protocols or applications that rely on IP
>>>>>    fragmentation if the protocol or application is to be run only in
>>>>>    environments where IP fragmentation is known to be supported."
>>>>>
>>>>> I'm wondering if there should be a bit more nuance here to make the
>>>>> recommendation clearer. Do we think there is a case where an application
>>>>> protocol developed in the IETF will be known to only run in environments where
>>>>> fragmentation is supported? If we don't think developing such a protocol would
>>>>> be in scope for the IETF, then I'm wondering if that case should be called out
>>>>> explicitly with a stronger normative requirement.
>>>>>
>>>> Alissa,
>>>>
>>>> Are you distinguishing between protocol development and application
>>>> development?
>>>
>>> I’m specifically wondering about application protocols (as distinct from other protocols) developed in the IETF (as distinct from developed elsewhere). Sometimes we use BCPs to guide future work in the IETF specifically, and it seemed to me that in that specific slice — IETF-developed application protocols — we may be able to make a stronger recommendation since we can’t be sure of the environment in which any given application protocol would be deployed (I think, but would be open to arguments otherwise).
>>
>> fwiw, I agree with what I think Alissa is saying. Unless we actually *implement* a mechanism to define and support limited domains (draft-carpenter-limited-domains) protocol designers cannot safely make assumptions such as "fragmentation works".
>>
>> Maybe this paragraph needs to be more of a health warning than a somewhat dubious RFC2119 statement. At least, "should not ... unless" might be a better formulation than "MAY ... if".
>>
>>     Brian
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>
> .
>