Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-6man-rfc4941bis-10

Alissa Cooper <alissa@cooperw.in> Thu, 22 October 2020 00:53 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198643A0B22; Wed, 21 Oct 2020 17:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=ercUD1qV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BqDQyTE4
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 ahdOBr3GRpcY; Wed, 21 Oct 2020 17:53:53 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6C83A0B1A; Wed, 21 Oct 2020 17:53:53 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 06A8EB81; Wed, 21 Oct 2020 20:53:51 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 21 Oct 2020 20:53:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=fc+rYmtqwAX7bukwsE72+6h FnkyMO4p25Zg2/yRWtRY=; b=ercUD1qVNDzzwua9rytF94V0yPzFVDc+ybUT/63 ZsICTdIryQwvtJISN2+UfV4cJqhx6SmVFFSahP3dUnYcZtQb4Mw+i1xCcwjVXS0x 8DmMK/Vo6Knsy4Mqp7YZvVoDOKhZbPcm7TNZ0bVF21YGnYmxweSVr93uQY5ku/Ir Qxv3TDVIctspFYc+q4nDsLW5y4KWyGyPVVCDtnjsGIEUt9iOVTV3vc2z/8YtJdlg JDEidI8zay2sSXdJuwG8j9hz+b7Dt0zjYxvNgB7HpITSuD8VQc2eE6W/3WpVZYET e3uogPkIX/Qc4gibN//TU3gOoPuBNwZIY4SkhP+c6AAuRlA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=fc+rYm tqwAX7bukwsE72+6hFnkyMO4p25Zg2/yRWtRY=; b=BqDQyTE4wF886k285H0yqQ 7d5I0PnzoeuDQtwsD2q531D8chzWqgvf28gD/T3cExVWwWsX5T12ZdovxgmJ58r7 I+/SkWSzKyx8iA47RlpTpXiM6Pvx2qYYIFr6KM3EawFpvkSGd3PSZJiGn3gFmstH +rGC3cM6WlLJdbk2degt3DJMOo2Y4zIqDBbzMd872LiTJJTdXIqV+JyjWzezYTBk ErzB3J++ykofEZ2JLTXT5fEqjnNls6q2BuAJqmYjh7HQiEi6uo6SnNCuI+SmOqrs 0NOJyuTMXCJkoQnHvDpInczgjpclGAFmaW9VdAlzFda1WXC9EEH/x2hQMOVVClYQ ==
X-ME-Sender: <xms:HdiQX42NGk7aQillSH7hRw4PDLGhqkqV6Txo3gssV1EBkc3cES-6BQ> <xme:HdiQXzEPbSgy2_drFYcV0Och6ApmzeDTYHlMwXJui2n37Bk1VU_K2WZ88hn4Lmkls Q2X53npqpYvJZ-Qsg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeeigdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrghtth gvrhhnpeelteekheffkeeuuedutedviedutedvtdffheeigeetjeelhfdtteeiffdvudeu teenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrie ehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl ihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:HdiQXw7WoagDOQe7tFfSMJU-ybElpNdGwlWt8gacQmOB8ry1WaeRCA> <xmx:HdiQXx0kBPHgdoiptdfdD8aiIeNtW8w87Fzps14kDQnJMdSPq16TpA> <xmx:HdiQX7EyNQSQf04Fw8bR1XC26wjcPRfrt3pgee05Z4ckQiHfil9Ufg> <xmx:H9iQXzBEVFqUSRow9Y9D4SUr0vwH3Dj7etHy13QIoYruweP-vF2Bxw>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 80CFE3280060; Wed, 21 Oct 2020 20:53:48 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Message-Id: <D806209C-9E77-4AF8-A6AC-F5504E10DA38@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9E1C767F-60D4-470F-BD32-135ACEBDA1A8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-6man-rfc4941bis-10
Date: Wed, 21 Oct 2020 20:53:46 -0400
In-Reply-To: <4288E75B-5B41-4DD1-AE17-FF58D54F0D84@vigilsec.com>
Cc: Fernando Gont <fgont@si6networks.com>, draft-ietf-6man-rfc4941bis.all@ietf.org, IETF Gen-ART <gen-art@ietf.org>, ipv6@ietf.org, last-call@ietf.org
To: Russ Housley <housley@vigilsec.com>
References: <159985539023.6692.3362899198639789498@ietfa.amsl.com> <a4dab342-219a-0f54-9972-623146d3a5d3@si6networks.com> <B7F58E44-B48B-43F5-917A-262A21B70C38@vigilsec.com> <cf44056d-6c6e-7766-01a7-6741398969f8@si6networks.com> <4288E75B-5B41-4DD1-AE17-FF58D54F0D84@vigilsec.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qms55a_pqmjawrflRTUFUDrrXE8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2020 00:53:55 -0000

Russ, thanks for your review. Fernando, thanks for making the updates. I entered a Yes ballot.

Alissa


> On Sep 16, 2020, at 9:08 AM, Russ Housley <housley@vigilsec.com> wrote:
> 
> 
> 
>> On Sep 16, 2020, at 7:39 AM, Fernando Gont <fgont@si6networks.com> wrote:
>> 
>> Hi, Russ,
>> 
>> On 13/9/20 14:46, Russ Housley wrote:
>>> Fernando:
>>>> Thanks a lot for your comments! In-line....
>>>> 
>>>> On 11/9/20 17:16, Russ Housley via Datatracker wrote:
>>>>> Reviewer: Russ Housley
>>>>> Review result: Almost Ready
>>>> [....]
>>>>> Major Concerns:
>>>>> In Section 2.2, the discussion of DNS names comes out of the blue.  In
>>>>> RFC 4941, there was context for this discussion that has been dropped
>>>>> from this document.  Some context is needed.
>>>> 
>>>> I reared the text, but I don't find it as "coming out of the blue". I guess one could add something to Section 2.1 to include DNS names... but, at the end of the day, the name is just another identifier.
>>>> GRANT ALL ON wp_si6networks.* TO 'wp_si6networks'@'localhost';
>>>> Or put another way, I'm not sure what's the "context" I would add if asked to.
>>>> 
>>>> Thoughts?
>>> This point from RFC 4941 is what I was talking about.
>>>   One of the requirements for correlating seemingly unrelated
>>>   activities is the use (and reuse) of an identifier that is
>>>   recognizable over time within different contexts.  IP addresses
>>>   provide one obvious example, but there are more.  Many nodes also
>>>   have DNS names associated with their addresses, in which case the DNS
>>>   name serves as a similar identifier.  Although the DNS name
>>>   associated with an address is more work to obtain (it may require a
>>>   DNS query), the information is often readily available.  In such
>>>   cases, changing the address on a machine over time would do little to
>>>   address the concerns raised in this document, unless the DNS name is
>>>   changed as well (see Section 4).
>> 
>> I see.
>> 
>> How about if we add back these bits, with the text resulting in:
>> ---- cut here ----
>>  One of the requirements for correlating seemingly unrelated
>>  activities is the use (and reuse) of an identifier that is
>>  recognizable over time within different contexts.  IP addresses
>>  provide one obvious example, but there are more.
>> 
>>  Many nodes have DNS names associated with their addresses, in which
>>  case the DNS name serves as a similar identifier.  Although the DNS
>>  name associated with an address is more work to obtain (it may
>>  require a DNS query), the information is often readily available.  In
>>  such cases, changing the address on a machine over time would do
>>  little to address the concerns raised in this document, unless the
>>  DNS name is changed as well (see Section 4).
>> 
>>  Web browsers and servers typically exchange "cookies"
>>  with each other [RFC6265].  Cookies allow web servers to correlate a
>>  current activity with a previous activity.  One common usage is to
>>  send back targeted advertising to a user by using the cookie supplied
>>  by the browser to identify what earlier queries had been made (e.g.,
>>  for what type of information).  Based on the earlier queries,
>>  advertisements can be targeted to match the (assumed) interests of
>>  the end-user.
>> ---- cut here ----
>> 
>> ?
>> 
>> Would this address your concern?
> 
> Yes, thanks.
> 
> Russ
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org <mailto:Gen-art@ietf.org>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>