Re: ietf Digest, Vol 142, Issue 183

Wout de Natris <denatrisconsult@hotmail.nl> Mon, 25 May 2020 10:12 UTC

Return-Path: <denatrisconsult@hotmail.nl>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD063A0AE4 for <ietf@ietfa.amsl.com>; Mon, 25 May 2020 03:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 JZELoqNExigb for <ietf@ietfa.amsl.com>; Mon, 25 May 2020 03:12:35 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-oln040092074024.outbound.protection.outlook.com [40.92.74.24]) (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 0C37E3A0AE5 for <ietf@ietf.org>; Mon, 25 May 2020 03:12:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QUZiQMfb0IOjALIxUDPH2aU+TNrGgHbV4eZj4/r2B6rhsp5G14UJzchCnv50MrO+2kpzJtMUszlMnA5PP5WVtdzq8c7515+VbIZWj0F0iVTUclCcCbQ9IxusMTxdZUyRvZUzTxiUrkPWijgVQYgEINW3tNGeC7h1DylEy2CwBL8ZT6b2apsWzox1+/LwXqdFi/ZihT/LR3YcDDNJ9hmYQ540JaGvGmVm9NZ0biZrIhK1RX/ok+dkizBR7kahL6zWkjGiDq1R8a20tRC7dlsa5Grbi/xdaMOoZL9wzZyY2fo7zjwLhrQne+VIArCNSOS/wWy5lBgP9FP4TRVyPPlvwg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yfPkZt25xe+ja+jJOeBu2k5kZbW8V0saGkgx2/bfSSA=; b=OW8nqeiasJyhlC4/Mrn+hvCu7AkmKy9NCj2xzvniylEmr0tEFY20/sLYox2EvPVechFl4qBSql99yiMDjOh6NZNXgSwtFTkoQ6xyZMaCutN2+PG12M9BMDCdRRuP8rxX9NOxHxZ9fLBtmRltr+r4YJEU9jHL4lvv1mEE508qEObFCoHEc5SxI8WXEtABTnNsglAnaGLtYCDejFW69+hj6RqOfwLpHcAQIbewNiiMh1a2Wlbc5e+4DcCql4ExLvdAy5zOKkWpMRHmWPwhKG1NwI7/UQ3VSa47Jnaxweld7YrCtKkOEWywLQi9qb/dyx39HLDwm2/vArKXycUvCpgTTQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
Received: from HE1EUR04FT017.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0d::4e) by HE1EUR04HT139.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0d::67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Mon, 25 May 2020 10:12:32 +0000
Received: from AM0PR05MB6564.eurprd05.prod.outlook.com (2a01:111:e400:7e0d::48) by HE1EUR04FT017.mail.protection.outlook.com (2a01:111:e400:7e0d::63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Mon, 25 May 2020 10:12:32 +0000
Received: from AM0PR05MB6564.eurprd05.prod.outlook.com ([fe80::89d2:dbed:85cd:70db]) by AM0PR05MB6564.eurprd05.prod.outlook.com ([fe80::89d2:dbed:85cd:70db%7]) with mapi id 15.20.3021.029; Mon, 25 May 2020 10:12:32 +0000
From: Wout de Natris <denatrisconsult@hotmail.nl>
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: ietf Digest, Vol 142, Issue 183
Thread-Topic: ietf Digest, Vol 142, Issue 183
Thread-Index: AQHWBDQS5BN8JpvePU2W8uqrLNt9Nai45xTB
Date: Mon, 25 May 2020 10:12:32 +0000
Message-ID: <AM0PR05MB65645FA319B09B6C421C2B9EC2B30@AM0PR05MB6564.eurprd05.prod.outlook.com>
References: <mailman.5669.1585312407.9580.ietf@ietf.org>
In-Reply-To: <mailman.5669.1585312407.9580.ietf@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:8C252C67C68F611AF13E5EDA7373A7ED9C52C3F610AE7FF465DE0C77E291AF40; UpperCasedChecksum:D5506BF21B400D20253ADAFADC537AA19ED1BF7E1A20E016611574E4167F9040; SizeAsReceived:6844; Count:45
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [T4TIIqKjzri1eE/Vzi0+QBPT4SnvW5f5]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: ab52eeeb-913d-4a67-a952-08d80094236e
x-ms-traffictypediagnostic: HE1EUR04HT139:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /cu6s7OiRTpAsOkol8XHWL6mJGoJ+U6YmsKhg3wSZyNDKu2IvsKBQUS3JuIgnfF54cAnZgx63OzGKkipQ6PEcF0qaPcwzXsa6bVc9r+9QxdZsDxJ18435puus7RqVuH4R9SQcFpVRWVhWcL24X/KJkTxUkN730odWQMd4nO4mvmlC2sTnx8cty0THe/Li0fiOjYbnv1OQHPdjUwWfLumslHejMMy/QONItU5wdwMtVxo7wF1la9y3bkzGG4AIj6B
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR05MB6564.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901;
x-ms-exchange-antispam-messagedata: 47mtfmSLQbfW1qVm4Z0Ie8CfCg37nW3uJVFMWBjbLUgoIut222OmheDTZLqQSEXoYs01LN/9SbAawAo6f6Bg8WokfCKAVu6nehyjw6Vn6PF3QLYyvXthg+/n4omI6297y8NWXdVR0C0IZsBj6/UWiA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR05MB65645FA319B09B6C421C2B9EC2B30AM0PR05MB6564eurp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: ab52eeeb-913d-4a67-a952-08d80094236e
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2020 10:12:32.1740 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR04HT139
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/uDqER5jKIZ7UCatI0ZhnmaUOjwA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2020 10:12:44 -0000

Re: A report on certain standards (was Re: United Nations report on Internet standards)

Dear all,

Since the start of this discussion early March, our world has significantly changed, so I hope this email finds you well.

Following up on the discussion concerning the IGF report. Currently a proposal is put to the IGF's organising committee, the Multistakeholder Advisory Group, to organise a so called policy track on the deployment of internet and ICT standards and best practices for the years 2021 and 2022. It has a very clear goal: Accelerating the speed of deployment.

The project has the recommendations of the report as starting point and my question to you is: who is interested in contributing to its chance to be successful? The following topics are foreseen.

1) Drive demand of secure ICT products and services, including deployed standards, e.g. through procurement at governments and larger corporations.
2) Involvement of more stakeholders to successfully apply pressure on decision makers in industry. E.g, consumer organisations, media, regulators, privacy advocates, trade organisations, etc.
3) Interaction between technical community and others. E.g., assisting in the dissemination of new standards in language others understand and can immediately act upon through testing, writing, adding, demanding, etc.
4) Education. Change the curricula of ICT classes at all levels. From vocational to university to include security, internet architecture and governance.
5) Building bridges between all stakeholders.
6) Assist developing nations with procurement of more secure ICT products.

So, to make sure, this is what the project is not.
1) There will be no interference with any standard body nor its internal processes. The demarcation line is the agreed upon standard/best practice.
2) No drive for legislation. No one wants it, and it shouldn't be needed.
3) It is much wider than IETF standards, as has been noted in past comments on the list. The term was used in a broad sense only for readability of the report.

If the project starts, a few volunteers from the technical community would be welcome as experts, liaisons, "translators", assisting in creating best practices for procurement lists, etc.

Please let me know should you be interested.

Best regards,

Wout de Natris




- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
De Natris Consult

Kamerlingh Onnesstraat 43                                                        Tel: +31 648388813

2014 EK Haarlem                                                                          Skype: wout.de.natris

denatrisconsult@hotmail.nl<mailto:denatrisconsult@hotmail.nl>

http://www.denatrisconsult.nl

Blog http://woutdenatris.wordpress.com

________________________________
From: ietf <ietf-bounces@ietf.org> on behalf of ietf-request@ietf.org <ietf-request@ietf.org>
Sent: Friday, March 27, 2020 1:33 PM
To: ietf@ietf.org <ietf@ietf.org>
Subject: ietf Digest, Vol 142, Issue 183

Send ietf mailing list submissions to
        ietf@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
        ietf-request@ietf.org

You can reach the person managing the list at
        ietf-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ietf digest..."


Today's Topics:

   1. Re: A report on certain standards (was Re: United Nations
      report on Internet standards) (Stephane Bortzmeyer)
   2. @EXT: RE: A report on certain standards (was United Nations
      report on Internet standards) (Marcolla, Sara Veronica)
   3. Re: NomCom eligibility & IETF 107 (Lars Eggert)
   4. United Nations report on Internet standards (Andrew Campling)


----------------------------------------------------------------------

Message: 1
Date: Fri, 27 Mar 2020 09:10:20 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Wout de Natris <denatrisconsult@hotmail.nl>
Cc: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: A report on certain standards (was Re: United Nations
        report on Internet standards)
Message-ID: <20200327081020.GC14620@sources.org>
Content-Type: text/plain; charset=utf-8

On Fri, Mar 20, 2020 at 10:57:31AM +0000,
 Wout de Natris <denatrisconsult@hotmail.nl> wrote
 a message of 238 lines which said:

> The topic of choice became deployment of internet standards:
> e.g. DNSSEC, RPKI and BCP38, but also the OWASP top 10, ISO 27001
> and secure software;

Yes, the choice of ISO 27001 is strange. It is not an "Internet
standard" in any way, and it is just a set of bureaucratic rules,
without relationship with actual security.

> Others involve people with knowledge, i.e. your community, to assist
> in translating new standards into layman's speech and in
> dissemination to non-technical communities.

Many IETF participants already do it. The report contains zero idea on
how to do it better or more broadly. (The fact that the report does
not mention that outreach must be done in the local language is a
weakness.)

But the report has other weaknesses:

* there are several unsubstantiated claims such as "some standards,
e.g. DNSSEC, may not have been thought through sufficiently". But
there is no detail: which problems do you see with DNSSEC? How to
improve it? IETF would like to create a 4033-bis with problems fixed.

* the report uses the very common narrative "The protocols or internet
standards, in other words were created without security in mind. At
best it was considered, after which it was decided security would not
be a priority. All the standards that are discussed here can in a way
be seen as digital band aids, fixing what only in hindsight was
flawed." I suggest that you read RFC 5218 for a good criticism of the
clich? "protocole should be designed with security in mind". Even now,
with the knowledge we have, designing secure systems is hard.

* the report keeps to the very outdated claim that there are two sort
of standards, official ones and the others. It even pretends that ISO
is more "official". That's not true. Except for the rare cases where a
law mandates such or such standard (which is not the case of ISO
27001, at least in my country), whether a standard is issued by IETF,
W3C, ISO or whatever, it is a standard, period.

* the report contains several criticisms without any
counter-arguments. For instance, "None of these organisations [the
RIRs] have tools to retract these resources when abused or otherwise
used in wrong ways."  The report seems to ignore that it would be
pointless: a RIR can withdraw an allocation, it will still be used,
and impossible to re-allocate. (RPKI may change that.)

* another example where the report is technically questionable is when
it says "create a new internet. Work on this solution is actually
being carried out and published on". (Which is substantiated by a
reference to the Cerre report which, itself, mentions RINA and SCION,
which says a lot about its credibility.)

> To focus not only on the technicians that have to deploy physically,
> but on those who can influence decisions to deploy and those
> deciding on the financial and resource wherewithal to deploy. Many
> participants, including IETF active, agreed that steps outside of
> the technical realm are necessary for these standards -and not only
> the IETF ones as you could see- to be deployed in a serious way,
> making all internet users more secure immediately and
> indiscriminately. Ideally without primarily government involvement.

The report is also problematic in what it does not mention. It is
silent about political disagreements. If encryption took so long to be
deployed, it was not because of technical issues but because several
important stakehoders activery resisted, because they want to ability
do conduct surveillance. No amount of outreach will make people adopt
a technical standard which goes against their interests. The tussle is
unavoidable.




------------------------------

Message: 2
Date: Fri, 27 Mar 2020 09:47:58 +0000
From: "Marcolla, Sara Veronica" <Sara.Marcolla@europol.europa.eu>
To: 'Stephane Bortzmeyer' <bortzmeyer@nic.fr>
Cc: "'ietf@ietf.org'" <ietf@ietf.org>
Subject: @EXT: RE: A report on certain standards (was United Nations
        report on Internet standards)
Message-ID: <c197c137d6704c2bb2c0085f1ff7066c@elvas.europol.eu.int>
Content-Type: text/plain; charset="utf-8"

I read your points, and if I may add another issue to the list: governments are not monolithic actors in this field.

Different branches of any given government might not be perfectly aligned on the priorities to follow. However, technical engagement of government representatives - without 'special treatment' happens, and quite fruitfully for all parties involved - for example at RIR levels. Of course, discussions there might be a notch less technical in a strict sense, but policy considerations, security considerations, and public safety considerations have increasingly found places in RIR policy developments thanks to governments investing time and effort: nobody lives in isolation, and we should learn improved ways of cooperation indeed.


Kind regards,

Sara Marcolla

Europol - O3 European Cyber Crime Centre (EC3)
www.europol.europa.eu<http://www.europol.europa.eu>



-----Original Message-----
From: ietf <ietf-bounces@ietf.org> On Behalf Of Stephane Bortzmeyer
Sent: 27 March 2020 09:10
To: Wout de Natris <denatrisconsult@hotmail.nl>
Cc: ietf@ietf.org
Subject: Re: A report on certain standards (was Re: United Nations report on Internet standards)

On Fri, Mar 20, 2020 at 10:57:31AM +0000,  Wout de Natris <denatrisconsult@hotmail.nl> wrote  a message of 238 lines which said:

> The topic of choice became deployment of internet standards:
> e.g. DNSSEC, RPKI and BCP38, but also the OWASP top 10, ISO 27001 and
> secure software;

Yes, the choice of ISO 27001 is strange. It is not an "Internet standard" in any way, and it is just a set of bureaucratic rules, without relationship with actual security.

> Others involve people with knowledge, i.e. your community, to assist
> in translating new standards into layman's speech and in dissemination
> to non-technical communities.

Many IETF participants already do it. The report contains zero idea on how to do it better or more broadly. (The fact that the report does not mention that outreach must be done in the local language is a
weakness.)

But the report has other weaknesses:

* there are several unsubstantiated claims such as "some standards, e.g. DNSSEC, may not have been thought through sufficiently". But there is no detail: which problems do you see with DNSSEC? How to improve it? IETF would like to create a 4033-bis with problems fixed.

* the report uses the very common narrative "The protocols or internet standards, in other words were created without security in mind. At best it was considered, after which it was decided security would not be a priority. All the standards that are discussed here can in a way be seen as digital band aids, fixing what only in hindsight was flawed." I suggest that you read RFC 5218 for a good criticism of the clich? "protocole should be designed with security in mind". Even now, with the knowledge we have, designing secure systems is hard.

* the report keeps to the very outdated claim that there are two sort of standards, official ones and the others. It even pretends that ISO is more "official". That's not true. Except for the rare cases where a law mandates such or such standard (which is not the case of ISO 27001, at least in my country), whether a standard is issued by IETF, W3C, ISO or whatever, it is a standard, period.

* the report contains several criticisms without any counter-arguments. For instance, "None of these organisations [the RIRs] have tools to retract these resources when abused or otherwise used in wrong ways."  The report seems to ignore that it would be
pointless: a RIR can withdraw an allocation, it will still be used, and impossible to re-allocate. (RPKI may change that.)

* another example where the report is technically questionable is when it says "create a new internet. Work on this solution is actually being carried out and published on". (Which is substantiated by a reference to the Cerre report which, itself, mentions RINA and SCION, which says a lot about its credibility.)

> To focus not only on the technicians that have to deploy physically,
> but on those who can influence decisions to deploy and those deciding
> on the financial and resource wherewithal to deploy. Many
> participants, including IETF active, agreed that steps outside of the
> technical realm are necessary for these standards -and not only the
> IETF ones as you could see- to be deployed in a serious way, making
> all internet users more secure immediately and indiscriminately.
> Ideally without primarily government involvement.

The report is also problematic in what it does not mention. It is silent about political disagreements. If encryption took so long to be deployed, it was not because of technical issues but because several important stakehoders activery resisted, because they want to ability do conduct surveillance. No amount of outreach will make people adopt a technical standard which goes against their interests. The tussle is unavoidable.


*******************

DISCLAIMER : This message is sent in confidence and is only intended for the named recipient. If you receive this message by mistake, you may not use, copy, distribute or forward this message, or any part of its contents or rely upon the information contained in it.
Please notify the sender immediately by e-mail and delete the relevant e-mails from any computer. This message does not constitute a commitment by Europol unless otherwise indicated.

*******************

------------------------------

Message: 3
Date: Fri, 27 Mar 2020 13:53:06 +0200
From: Lars Eggert <lars@eggert.org>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Barry Leiba
        <barryleiba@computer.org>, IETF discussion list <ietf@ietf.org>
Subject: Re: NomCom eligibility & IETF 107
Message-ID: <9C9C6A76-DA41-44F1-86FF-CCEA89227732@eggert.org>
Content-Type: text/plain; charset="us-ascii"

Hi,

On 2020-3-26, at 19:54, Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org> wrote:
> I want to get the largest pool of candidates.

so that's a worthwhile goal.

But: My guess is that any fine-tuning here would not make a huge difference to the size of the pool of people eligible to be considered as voting members.

The pool that we actually want to maximize is the sub-pool of eligible people *who volunteer to be considered*. If we can convince more eligible people to actually volunteer it would have a much more sizable impact (again, a guess.)

Anyone got data on #eligible vs. #volunteered?

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mailarchive.ietf.org/arch/browse/ietf/attachments/20200327/fac074ed/attachment.asc>

------------------------------

Message: 4
Date: Fri, 27 Mar 2020 12:33:21 +0000
From: Andrew Campling <andrew.campling@419.consulting>
To: "Andrew.Alston@liquidtelecom.com"
        <Andrew.Alston@liquidtelecom.com>, "ietf@ietf.org Discussion"
        <ietf@ietf.org>
Subject: United Nations report on Internet standards
Message-ID:
        <LO2P265MB05735A9D5C3BB8EB4C73790FC2CC0@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>

Content-Type: text/plain; charset="iso-8859-1"

On Fri, 27 March 2020 07:53 Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:

> Basically what I am saying here is that I am not sure that it is the IETF and its
> methods of functioning that are the problem - it is in some cases the outright
> dominance of certain vendors and their attitudes towards engineers that are not
> from the same fold, who's views and opinions are automatically discarded, and
> the vendors that end up almost attempting to play the role of chair.  I've seen a
> vendor openly declare discussion on a topic closed - despite the fact that, that is
> very much the role of the chair - and there was no one to call them out.
>
> You want wider participation from engineers and operators - the dominance and
> bullying by certain vendors has to be stopped.  That is the real problem in my view

There does seem to be an issue of diversity within the IETF cohort, specifically diversity of thought.  Some of the responses to Vittorio's original post betray an in tolerance of "government", ignoring the fact that governments in democracies do represent their citizens, so will necessarily have a very different perspective on many matters than, say, an individual engineer in a tech company.  Some people seem to assert in various ways that the Internet does and should reside outside of the jurisdiction of government, combined with a willingness to ignore some of the negative impacts that it and its related technologies can have on people.  This has led governments to impose measures to force better behaviour in areas such as privacy and hate speech when dialogue might have led to better solutions.

An example of divergence of views is around security and content.  In other circles it is pretty uncontentious to expect malware and botnets to be blocked whereas some IETF participants appear to regard that as censorship.  Similarly, suggestions that child abuse material should be blocked are also viewed with suspicion, with some categorising any such arguments "for the children" as a flimsy excuse for censorship.  They will however, justify technologies that could arguably facilitate the dissemination of malware or aid the anonymous distribution of child abuse materials because the same technologies could benefit dissidents (this is not always supported with evidence).  With other stakeholder groups, blocking of malware, child abuse material etc would not view viewed as controversial, not blocking it would be.

Despite being an open community, barriers to full and effective participation in the IETF are high.  More generally, and to broaden the multi-stakeholder point beyond government, the lack of input from a broad range of stakeholders can lead to situations where the impact of changes to existing standards or the introduction of new ones are not fully considered.  It is na?ve to focus solely on the technical aspects as things are rarely that simple: the Internet does not exist in a vacuum, its impacts can be wide and varied, and it's not always a force for good as noted above.

In my view it is possible to do better than this and I would urge people to consider ways to engage with and gain input from other stakeholder groups effectively.  This is certainly an issue that will be discussed at EuroDig 2020 and, I suspect, may find its way onto the agenda at the next IGF conference; it would be great to have substantive input from the IETF to this debate.


Andrew Campling

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/ietf/attachments/20200327/5f811bb6/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
ietf mailing list
ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


------------------------------

End of ietf Digest, Vol 142, Issue 183
**************************************