IETF Logo Mail Archive

Re: [v6ops] draft-xie-v6ops-network-happyeyeballs

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 27 November 2018 13:28 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68EE130DFF for <v6ops@ietfa.amsl.com>; Tue, 27 Nov 2018 05:28:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 uqYoRCrG7AT8 for <v6ops@ietfa.amsl.com>; Tue, 27 Nov 2018 05:28:46 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 45DB0129385 for <v6ops@ietf.org>; Tue, 27 Nov 2018 05:28:46 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 99EEEB9; Tue, 27 Nov 2018 14:28:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1543325323; bh=S1tx+FX9YrTeVTDP1ed/y7b/ApmRPhLcee3hqri5DjE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bdcTuYe77stIO3XPHAYCbf0uHkiFqHApFISqseiHqC91fG4Uof5NeQjG2Jx/yQ9sm U8+v3GaZs37Dt5NufY+KXU9PpYekszK3Jcqti68ZimdM7s7egw4skXGJBrZb5uSfvs LnJ+k7Sv99UM+5D+r0aVXBp3viXlCSv2i2bLJGHU=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 94B34B1; Tue, 27 Nov 2018 14:28:43 +0100 (CET)
Date: Tue, 27 Nov 2018 14:28:43 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: Ron Bonica <rbonica@juniper.net>, "v6ops@ietf.org list" <v6ops@ietf.org>
In-Reply-To: <30D71C7B-1FBF-49C2-A5C6-40948550CA69@consulintel.es>
Message-ID: <alpine.DEB.2.20.1811271424170.7766@uplift.swm.pp.se>
References: <BYAPR05MB42453683C869E9A5327DA903AED70@BYAPR05MB4245.namprd05.prod.outlook.com> <alpine.DEB.2.20.1811271231060.7766@uplift.swm.pp.se> <30D71C7B-1FBF-49C2-A5C6-40948550CA69@consulintel.es>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6crMCJrg8GopVWlJgNAwbBbr4Dk>
Subject: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 13:28:49 -0000

On Tue, 27 Nov 2018, JORDI PALET MARTINEZ wrote:

> Hi Mikael,
>
> I got the impression that when I originally proposed this, syslog was a privacy issue because it is sending data from "customers traffic" from their own devices to the ISP.
>
> But in the actual proposal, the data is NOT from any customer, neither identifying the customer at all.
>
> So not sure to understand if we have failed to clearly describe the way we are measuring, or you'd in mind the previous document?

https://tools.ietf.org/html/draft-xie-v6ops-network-happyeyeballs-01#section-4

4.  Reporting IPv6 failures using syslog

    In order to simplify the reporting of the NHE failures, syslog
    ([RFC5424]) over UDP ([RFC5426]), MUST be used, by means of the
    default port (514) with IPv6-only.



What is this then? When I re-read it it's not clear if this is for 
operator-operator communication or between client HE and operator. If it's 
for operator-operator, how is this address discovered?

The reference to 4.1 about this doesn't make sense to me from a NHE 
perspective? Why is this conflating things with the NAT64 prefix?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email