Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 07 December 2020 22:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7CC3A0BBC for <iotops@ietfa.amsl.com>; Mon, 7 Dec 2020 14:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 p-0iHL02wZk5 for <iotops@ietfa.amsl.com>; Mon, 7 Dec 2020 14:24:57 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836FB3A0BA4 for <iotops@ietf.org>; Mon, 7 Dec 2020 14:24:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3ACB6389AE; Mon, 7 Dec 2020 17:27:04 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2RqrNHfXwhZS; Mon, 7 Dec 2020 17:26:56 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15592389AD; Mon, 7 Dec 2020 17:26:56 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 76CEB48F; Mon, 7 Dec 2020 17:24:47 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Henning Schulzrinne <hgs@cs.columbia.edu>, iotops@ietf.org, architecture-discuss@iab.org
In-Reply-To: <CACgrgBa+JMDBWWBotfQeJMc=LMbkH+JbkbQ_YkXS4GuccnbrVA@mail.gmail.com>
References: <f8486514-9726-68d0-2bc8-dccd4293017e@cs.tcd.ie> <DM6PR14MB317843CA2B3D67F6660F4F0DD7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <DM6PR14MB3178C1F8B6E4FD6E9FD9C8C4D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <DM6PR14MB317817FD62369A8E0FF93CA8D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <m2zh2sktty.wl-randy@psg.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> <CACgrgBa+JMDBWWBotfQeJMc=LMbkH+JbkbQ_YkXS4GuccnbrVA@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 07 Dec 2020 17:24:47 -0500
Message-ID: <28540.1607379887@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/TKgFltf2KqQT8MuBZDL3E_t9DEo>
Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2020 22:25:00 -0000

Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
    > It used to be that vendors announced end-of-life for products years after
    > introduction. For example, there was no way for a purchaser of Windows NT
    > to know, at purchase time, how long Microsoft was intending to support the
    > operating system. Now, better vendors seem to have started to make some
    > commitments, e.g., "this Android phone will receive new versions of the OS
    > for three releases and security updates until 2025". All the major Linux
    > distributions now have some kind of an LTS version, with long-term
    > stability and security/bug upgrades planned. There have been proposals (in
    > the UK?) of making vendors of IoT equipment state their support commitment,
    > so that a purchaser can choose "cheap" or "lasts a lifetime".

yes, that's in the upcoming legislation.
This document hints at it:
     https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/773867/Code_of_Practice_for_Consumer_IoT_Security_October_2018.pdf

This was a call for views that ended in September:
  https://www.gov.uk/government/publications/proposals-for-regulating-consumer-smart-product-cyber-security-call-for-views/proposals-for-regulating-consumer-smart-product-cyber-security-call-for-views

  Box 4 - Requirement 3 - Provide transparency on for how long, at a minimum,
  the product will receive security updates

  Exact wording and approach to be finalised

  The ‘defined support period’ for the relevant ‘product’ shall be published
  in an ‘accessible way’ that is ‘clear and transparent’.

  This clause aligns with provision 5.3-13 of European Telecommunications
  Standards Institute (ETSI) European Standard (EN) 303 645 v2.1.1.

    > One reason for not upgrading: OS dependencies. Apple Big Sur (and Catalina)
    > broke a lot of printer drivers, so I had a choice: Upgrade my OS or keep my
    > printer working. Dell, the distributor of the printers (made by Fuji-Xerox,
    > apparently) simply states that "due to circumstances beyond their control",
    > they won't be providing any Catalina/Big Sur printer drivers.

My mom's computer is just "too old", yet it is perfectly functional.

    > Given that most commercial systems are now assembled out of open-source
    > components, with customization or glue on top, you'd want some kind of
    > automated component checker. "17 of your components have not committed to
    > long-term support. Are you prepared to fix them yourselves?"

Some kind of expert system perhaps.
Who'd pay to maintain this?  And would it, itself, go out of support?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide