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

Joe Touch <touch@strayalpha.com> Wed, 07 August 2019 14:07 UTC

Return-Path: <touch@strayalpha.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 E358B120041; Wed, 7 Aug 2019 07:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Level:
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 UXUDvJb6nqXa; Wed, 7 Aug 2019 07:07:46 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FDD12003E; Wed, 7 Aug 2019 07:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=64Xwxmq7zeHdfBrp5mfh8+nwym+mpyqj8Z2BhDZuo00=; b=eY3tOSrRyoIyCtT6Jg682HZtR +x5sTN6rA2DhITebKANyL6R7Lw8q3dyJ8DK66m0u025V8CTrPIEPp7MSTC/rdKNN3r3JCFSAjZyJw h/5bBQQWoQLhtJuTcKfc9FE8MhX2j0otpPfXDa+reK3bjkI06+v42CumI/fG0Guox9yxYGtovZ5FI flypiTdWD6ru5yPC+L6uoUu6A5NpoQfo4UIpQj7/+G/v3iD2Sovt4l9irFlYLxfxDDPCJjvECI/Ya MJIdmz2NkvAWq0LBHjuhKjV0uCDPienbBSW2iRt5yvXQOCaWCSiK2tGv7kWqXALuMD2rNCYm+ijE1 RTEK6Wu4w==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56870 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1hvMbM-000RFm-NY; Wed, 07 Aug 2019 10:07:45 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_18A8AE1A-2B48-459E-B69F-1DDE2B55FA65"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <8f38a5fe-0eb8-d4a5-fd06-f8afab12e8f7@gont.com.ar>
Date: Wed, 07 Aug 2019 07:07:39 -0700
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, draft-ietf-intarea-frag-fragile@ietf.org, int-area <int-area@ietf.org>, intarea-chairs <intarea-chairs@ietf.org>, IESG <iesg@ietf.org>
Message-Id: <ECAF8DA5-8D8A-405B-ACDF-09EBB946DDFA@strayalpha.com>
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> <7056C34F-EF5E-4582-89FA-CA7C97A43028@strayalpha.com> <8ffc12ea-7b20-06f5-0ff8-3ba74a0c1bbc@gont.com.ar> <F6B05EE0-4C1F-45E1-AF06-A44E379C80BC@strayalpha.com> <8f38a5fe-0eb8-d4a5-fd06-f8afab12e8f7@gont.com.ar>
To: Fernando Gont <fernando@gont.com.ar>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/zzUpVAtxG0U9zLvkIMPlfn7LgIQ>
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 14:07:48 -0000


> On Aug 7, 2019, at 7:01 AM, Fernando Gont <fernando@gont.com.ar> wrote:
> 
> On 7/8/19 16:30, Joe Touch wrote:
>> Things that don’t work aren’t always either deprecated or security attacks.
>> 
>> And if we treat them as such, the remainder won’t be useful to anyone for anything.
> 
> What I meant is that, whether one likes it or not, at the point
> something does not work (for some meaningful level of failure rate), you
> cannot rely on it anymore. (that wrt the "deprecated" (in a colloquial
> way) bit).
> 
> Regarding security, there are times in which things don't work because
> vendors did such a poor job that supporting a given feature opens your
> networks or devices to attack. Particularly when a feature is not widely
> employed (if at all), it's not surprising that ops people resort to
> blocking the feature.
> 
> Not that I necessarily like it, but that's what reality seems to indicate.

Sometimes they indicate bugs — often that we ought to encourage be fixed. 

Otherwise, as I’ve said before and again above, we end up with the least of everything.

In this case, warning people that things might not work isn’t the same as “should avoid” or “don’t use”. It could be as simple as “check before relying on”, but let’s face it - the Internet is *best effort* throughout anyway, so even needing to say that seems redundant.

To the IESG: wordsmithing this document is a bad idea unless it comes with a substantial revision explaining the impact of stronger warnings AND is taken back to the WG for consensus.

Joe