Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.txt)

farzaneh badii <farzaneh.badii@gmail.com> Wed, 12 June 2019 18:50 UTC

Return-Path: <farzaneh.badii@gmail.com>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27063120148 for <hrpc@ietfa.amsl.com>; Wed, 12 Jun 2019 11:50:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 8JU2T7MAUXVF for <hrpc@ietfa.amsl.com>; Wed, 12 Jun 2019 11:50:33 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 EE41D120199 for <hrpc@irtf.org>; Wed, 12 Jun 2019 11:50:17 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id m29so19666861qtu.1 for <hrpc@irtf.org>; Wed, 12 Jun 2019 11:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kX8nBduck0RN3voD7OvblZkxatn0mY+QU/6WXNstc+E=; b=AyY933fc3eywFlkf1dgr2km1XSePxJubQ8Xc5JNCOjLv7TX1xD1IpjxQXApzRDLrbx /+60sPXhAfkHL10FH5k+ACamaBl8NLJLhkIrx9UusozdrJMDgnxSAZGOWl1rayxlwG2s 9HLFY1Y50/l9a/+FP3E+UM/4dLylD0S2ULUJoxzSIc1tHpZLQzOtUKPdVo5ctUPqnOvo xWyn4pKqeaTXHo0l+f8wo1U9cypo9W9Q6R7DYOvpHJoZi8hOAm07NG+qp2ooCnFwnGQN 8Q4bIKZaJTNG51d9C2m5p6U90b+ymXvWEyCsYqcZD/10znErTZVNOA2Ke8xC8D75yA4N b7yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kX8nBduck0RN3voD7OvblZkxatn0mY+QU/6WXNstc+E=; b=O/IoXy40Ax61moKAruSPw7ZVR7YCBmDlzN80exzi4a+3FXrR7pzjXnLZ7yWs8szJV6 uGBnKwpdoGWbc1PnOMKxVUZJ6u+bPl5r6r1VR5N0e1+OCbgHPIOst6epYA3HlY/ETL5D CSo9imxykQHM/ejZFHXQif1784FNq+uvQHFv5PSTqfxKpg1LmUb4C6M8bqIcxfR+7I2m dA6fF0N4OmqpHOMG853gXO61QN6Qx++lCbssbgU0KNKN4COtQFBeqyPXcFnnI/DkAgWw NLjaei8pmy19q5+ptgS1sSiDXRNXKOYj/IT8En2TqQ17qJhs4vc5+agBH/N9JB4bLn1x jAvw==
X-Gm-Message-State: APjAAAVFT8BVTyUPaHiOgxOts7hXuwXtQM/MX/onoaze2753yhjpj6pW /9pj+WS4QfXirVnMd/GKQRlwsS4Hek9tQOZPoCe+RA==
X-Google-Smtp-Source: APXvYqxm9a4Rr3Y+9VOV0jiyof9XIcAwFUfwH+X+6ibUJa2kOSWt8qHGlXdGJucw6yqOMhGaHfwNx7iaJRrIsdJpMaM=
X-Received: by 2002:ac8:24b8:: with SMTP id s53mr3123355qts.276.1560365416995; Wed, 12 Jun 2019 11:50:16 -0700 (PDT)
MIME-Version: 1.0
References: <155989623088.20255.12181969220178709616@ietfa.amsl.com> <C550D5BC-8062-4C58-8CEC-B82B2798C1D9@istaff.org> <71b7350e-cb75-aba1-1717-50d1069531b1@nielstenoever.net> <B8D9823F-2D42-42DF-AE8A-6E67532DA4D1@istaff.org> <d66b60ab-3aaa-d45d-3f47-d2c00f89119d@article19.org> <1ECD44BA-4BB1-47FD-87B5-E35A3B6DDCB6@istaff.org> <CAN1qJvA5BdbSJNkGADChmtmjHzww0Q5RcvXwwOC4rO7YT7DiVw@mail.gmail.com> <992B79C0-5B80-4710-B8CF-D87BC80FA2C3@istaff.org>
In-Reply-To: <992B79C0-5B80-4710-B8CF-D87BC80FA2C3@istaff.org>
From: farzaneh badii <farzaneh.badii@gmail.com>
Date: Wed, 12 Jun 2019 14:49:50 -0400
Message-ID: <CAN1qJvD+m+ecOWj8rY3v59u=qnxBH4zU8Z3G74R4tU38h6Eccg@mail.gmail.com>
To: John Curran <jcurran@istaff.org>
Cc: Amelia Andersdotter <amelia@article19.org>, hrpc@irtf.org, Niels ten Oever <mail@nielstenoever.net>
Content-Type: multipart/alternative; boundary="000000000000665e0e058b24e256"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/9RFwOUznJzWruXLAHT7uMyGAEp8>
Subject: Re: [hrpc] Protocol/Architecture consideration of Attribution & right of legal remedy (was: Re: I-D Action: draft-irtf-hrpc-guidelines-03.txt)
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "mail@nielstenoever.net" <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2019 18:50:35 -0000

Thanks John. That now makes better sense to me. We can discuss whether it
should be documented and how it should be documented. But we need to
consider many more aspects of it.
We need to understand what  "security" and "legal remedy"  means in IP.
What is "harm"? Harm is a very controversial term which can be interpreted
in various ways.

I suggest we have more discussion about the nuances before arguing about
the inclusion of your text.




Farzaneh


On Wed, Jun 12, 2019 at 2:05 PM John Curran <jcurran@istaff.org> wrote:

> On 12 Jun 2019, at 1:48 PM, farzaneh badii <farzaneh.badii@gmail.com>
> wrote:
>
>
> Frankly, John, what you are suggesting is outrageous.
>
> You don't have to always attribute the wrongdoing to a "person" or even a
> "location" to be able to establish jurisdiction and have access to a legal
> remedy and even preserve security. What you are suggesting will do more
> harm than good for human rights.
>
>
> Farzaneh -
>
> I’m not certain if you read what I wrote, but I certainly did _not_
> advocate that protocols/architectures have to always attribute to a person
> or location – the proposed text provides questions for protocol designers
> to consider in their design activities, not mandates or architectural norms
> to be followed.
>
> If you are correct in that there are cases where attribution isn’t
> necessary to provide access to a legal remedy, then it’s simply a matter of
> documenting (for a given protocol/architecture under assessment) why that
> is the case, since that’s one of the first questions asked in the proposed
> text:
>
> *"What, if any, mechanisms within the protocol or architecture are
> provided for a recipient of communications to obtain redress from
> communication which causes harm?  “*
>
> If redress is readily available, then it is indeed true that attribution
> is a non-issue.  It might be good to document an example of such a
> protocol, since most protocols recourse from “bad behavior” is
> disconnection, and that’s obviously not the same as legal remedy/redress.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
>
>