IETF Logo Mail Archive

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-16.txt

Bob Hinden <bob.hinden@gmail.com> Wed, 04 September 2019 00:20 UTC

Return-Path: <bob.hinden@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 4C13812006F for <int-area@ietfa.amsl.com>; Tue, 3 Sep 2019 17:20:11 -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 5Slnzmrq9RfK for <int-area@ietfa.amsl.com>; Tue, 3 Sep 2019 17:20:09 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 639C112004C for <int-area@ietf.org>; Tue, 3 Sep 2019 17:20:09 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id r17so1208450wme.0 for <int-area@ietf.org>; Tue, 03 Sep 2019 17:20:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UoCDeGKfBhjwrpZTetRzOD6OKCYhYHrPISI4cEIDOZ8=; b=Cx6MWMEZdrFAOafBRoAGuKhrA84W0N4S+rnexOZFI6zKvLkaC3j9kSq/5iPhqFphXZ oBQPL15O9lJWw0v/X3PlpONT1sPUUU2w0PcsVWhzVnutiE+ADO2Fv2dxjXd0Gbn60ONh +5lTQmrzdkcTSDRmnm17llWoZuhLUnq6w72vmzwMd649kJSNg0RyjM+o2eYDp3vVpzkx v7Y0mwH5izUSmQxJQRnoPiSUd8HsdxhmJJzAZ5HNxZ1eghnr1nCHXYz0ra06/lRdnlUW HpWuY7mWEvI4sMjYUvOcQKC3Lxa+WWQDt6IJYd09IXvBCBFiyJIIU6oD245bJwgLEGmW wZJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UoCDeGKfBhjwrpZTetRzOD6OKCYhYHrPISI4cEIDOZ8=; b=lt/epmBQEBBHeasSlaVF0HyORTQ5bRsp3oiZ/0Mgk1q33GHzB6BZTgqnqQvRIpgly3 /o9N6/m/3wiLxwWC1cvPnyx2KMED0pH91u5PuXhsZjlml8lpnEYdOfoxuspsOKALZ/Mx Ke3UcGlGIWAmZWqOuopWykyCngFiOGAPiF0HzbtTXTk6wXI7g5eqOHxUfGsRB4COY/fS Y/TG7mVLY98G3uM+OlO5HKlYSh0t2siZTJB1n2QTBST3wwPIVc/YAXjaExtFmSvcuR5Q 9Cm5pOgonKyuPyM7WcNs3SLqwkohtp+mNu6SkKYaQ4ychPkO5ukUmglJksghl/UQPYDf yDlw==
X-Gm-Message-State: APjAAAVJaut0KdAp/8azuyQvOcHkubYjB+50SWO0Gm8E7dPH2ai47j6i PenEfjXoxd0hR7XEfuBzcXA=
X-Google-Smtp-Source: APXvYqyw75iVb1+1ZjwaWWafIqJ3XIGTF6tS4IdqhhZUkKP5S5BkNqaa0kApliy8hLqeQ5KYiNKS6Q==
X-Received: by 2002:a1c:c189:: with SMTP id r131mr567394wmf.153.1567556407933; Tue, 03 Sep 2019 17:20:07 -0700 (PDT)
Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id a13sm13720306wrf.73.2019.09.03.17.20.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Sep 2019 17:20:07 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <DA9B4070-8306-4379-B177-BDE36A67C7CA@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_60BC8495-D135-484F-90C9-A963865ACF7B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 03 Sep 2019 17:20:03 -0700
In-Reply-To: <CALx6S35sX+vt0KP8kK_raaRNjpoctJtKnzD4kW3B5wCPbKuicQ@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Joe Touch <touch@strayalpha.com>, int-area <int-area@ietf.org>
To: Tom Herbert <tom@herbertland.com>
References: <156720070159.25823.9907888750637231986@ietfa.amsl.com> <cbc82eaa42b9f2f1c19fc248825861fc@strayalpha.com> <8551660F-9540-44BC-B775-7F15169E02ED@gmail.com> <CALx6S35sX+vt0KP8kK_raaRNjpoctJtKnzD4kW3B5wCPbKuicQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/ct6oIi5uaKJ4hFHtO5RJh7eXRgM>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-16.txt
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, 04 Sep 2019 00:20:12 -0000

Tom,

> On Sep 3, 2019, at 2:20 PM, Tom Herbert <tom@herbertland.com> wrote:
>> 
>> The relevant text in -16 is:
>> 
>>  6.1.  For Application and Protocol Developers
>> 
>>  Developers SHOULD NOT develop new protocols or applications that rely
>>  on IP fragmentation.  When a new protocol or application is deployed
>>  in an environment that does not fully support IP fragmentation, it
>>  SHOULD operate correctly, either in its default configuration or in a
>>  specified alternative configuration.
>> 
>>  While there may be controlled environments where IP fragmentation
>>  works reliably, this is a deployment issue and can not be known to
>>  someone developing a new protocol or application.  It is not
>>  recommended that new protocols or applications be developed that rely
>>  on IP fragmentation.  Protocols and applications that rely on IP
>>  fragmentation will fail to work on the Internet.
>> 
>> The text in the first paragraph is unchanged in this version of the draft and has been there for awhile.  The recommendation is still SHOULD NOT.   This does allow other usage if there is a good reason to do so.
> 
> Bob, I don't understand this change. The old text had a normative
> requirement (a MAY), but the new paragraph doesn't include any
> normative requirements. Why? It seems like the WG had come to
> consensus on the previous text, but the new text is substantially
> different beyond just being an edit.

The change was made to resolve an IESG Discuss.

The first paragraph is still normative and covers the second paragraph.  SHOULD NOT and MAY are related.  The second paragraph describes the controlled environment case in more detail.

The text in -15

   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.

This isn't workable.  How can a developer possibly know what environment the code is going to be running in?  For example, when code is checked into a Linux distribution, how would the developer know where it is going to be running and IP fragmentation is works reliably?

Bob

v2.23.0 | Report a Bug | By Email