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

Alissa Cooper <alissa@cooperw.in> Wed, 07 August 2019 00:11 UTC

Return-Path: <alissa@cooperw.in>
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 7EC0D12009C; Tue, 6 Aug 2019 17:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=dKvZt5mK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EUXR5fTQ
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 WD-6MhybBbfZ; Tue, 6 Aug 2019 17:11:52 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC0912008C; Tue, 6 Aug 2019 17:11:52 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7944C21111; Tue, 6 Aug 2019 20:11:51 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 06 Aug 2019 20:11:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=p QSk3uDjhuNv8VSiwZDOih378ijVZgbPiIEg1hCaCG4=; b=dKvZt5mKFxiKw19Fq 1GOo9f7XIzVSAFyq4c0LcGyBvVo9yQoLZHk8IR1ZumM+HD0QInj1Av6v01Mxfjmx Zz7GcnzkgrbU9HChdSkNH3ptoMFLLgnLLYXXyr4b09o5XRxWjAo+q4y9FFWlwhjc 0DePoAlTGIDgrURsYITrf5oFwgUHsSBn2jvV58x3mmLab5Lx7JSPXMziDUr9fEbi yaANrvaAXnqZNgSpPlK7aR8WQjXQlSSV46BS3/jHD7U7H+IePTm4y8oeUrsa4ITt qIs/+D4b9rysntEeZTvF2S6r55kZsI2z4iOK5MZWtGBw/zzVqS0V5m36XkeIwM9p /rwbg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=pQSk3uDjhuNv8VSiwZDOih378ijVZgbPiIEg1hCaC G4=; b=EUXR5fTQmJMvPqn11Vu1VJHtF0H5jf2FWs8UIMzmk2CQZOR3wDYT9K2Hf AAO2oYEZKcEViNQo+WS6/Zaws2fyCWbDHBWCONRtdT9uCv8DbvnZYWz5+rjuql4T KO+GQCjeGCQ0iNS0K2UdFOT7mZK7krwBbL+xboio4dwzYvMY0gldsNIx1mCRYrgO fQOSgA3FPrWodc5+/R+7JDd0C7yZ/OD968YI8At4mgwjNENY0DYkLK3EIa713PGY EFovN7BOq+BgqP0ES23Qb22WwaxjrrLttQM+J01c+4cCGmdJ8cbHcJXki0x3YpUP IOwpq+N2tDoF7953Vl5x6u7i4wnag==
X-ME-Sender: <xms:RhdKXcp2bfokBmBnTHVZptRvGOY11_of4_U9t3NztVCiuBnfO_5IhQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduuddgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrjedvnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:RhdKXZnKYanXDR9dQxA6vIucvUa06ehjRwB-X3gWbuYJbgWBMHA4UQ> <xmx:RhdKXaLuJzix9VkS-V4kZX66eD0NbiQP2X-4k8K8UpkgJPAKMWMtjA> <xmx:RhdKXbsejJ-XK02RVtZuvnWFhMxrHT1XALaKytIaC28NPNVj6RAI1A> <xmx:RxdKXcdNZ91bc459ha-bF2nJjKDE7dPGStls2rATmqYTgwKe-ef3jQ>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.72]) by mail.messagingengine.com (Postfix) with ESMTPA id E418E38008F; Tue, 6 Aug 2019 20:11:49 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <CALx6S35f9eH1SCFqWZoBtnFrqvdoXrhiPoPQTh2_w-LjwBzRSQ@mail.gmail.com>
Date: Tue, 06 Aug 2019 20:11:48 -0400
Cc: IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, draft-ietf-intarea-frag-fragile@ietf.org, int-area <int-area@ietf.org>, intarea-chairs <intarea-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B2DA394-E11A-46C1-8A45-76D59BAF0783@cooperw.in>
References: <156512344887.27340.5761295053779083959.idtracker@ietfa.amsl.com> <CALx6S35f9eH1SCFqWZoBtnFrqvdoXrhiPoPQTh2_w-LjwBzRSQ@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/-gTg1lzTBLoP7fpr9q5YmU9kE0Y>
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 00:11:55 -0000

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).

Thanks,
Alissa


> For instance, as written the requirements would allow a
> UDP application developer to send 64K datagrams which might work
> perfectly fine and be the best solution in their environment that they
> know properly supports fragmentation.
> 
> Tom
> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Section 3.8.2: If there is any chance we think this situation might improve
>> before this RFC-to-be gets obsoleted one day, I might suggest:
>> 
>> s/The security policy described above is implemented incorrectly on
>>   many consumer CPE routers./The security policy described above has been
>>   implemented incorrectly on many consumer CPE routers./
>> 
>> Section 3.9: s/Another recent study/Another study/
>> 
>> 
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area