Re: [mif] next step for MIF PVD configuration

Mikael Abrahamsson <swmike@swm.pp.se> Sun, 03 April 2016 13:00 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDC012D541 for <mif@ietfa.amsl.com>; Sun, 3 Apr 2016 06:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gXORLu4UewVY for <mif@ietfa.amsl.com>; Sun, 3 Apr 2016 06:00:10 -0700 (PDT)
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 656EA12D539 for <mif@ietf.org>; Sun, 3 Apr 2016 06:00:10 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 34ACCA2; Sun, 3 Apr 2016 15:00:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1459688408; bh=DzDwawSQGu3kqTs6TWae//P9/tuiTC+7Nr0T2Cruwew=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ib4LVWWCAfNBQXUcdwUMTCh9ICEnxhs+M/E93nMFUa5bo1LNUUPxnLi9aanLeEzNz PnevThgLS3lrf+ZLu+wRruFJcv49gcYt5FO3EhfaM/+QbbJ42PI/AEEmB1Jf1Q6sZb USI/SIYHEOKj7gUlfeHLWYtwKs6loqQAHpOGgtPs=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2E8C2A1; Sun, 3 Apr 2016 15:00:08 +0200 (CEST)
Date: Sun, 03 Apr 2016 15:00:08 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <B1328946-34AD-4222-813E-3B7A67B5B6CA@gmail.com>
Message-ID: <alpine.DEB.2.02.1604031455150.31096@uplift.swm.pp.se>
References: <COL125-W396ADD4D31445DAE7867D3B1BA0@phx.gbl> <56D44703.7050700@fer.hr> <256A8C0C-EEED-4AF4-8B59-DD8109AB1519@gmail.com> <56D82434.5020803@fer.hr> <alpine.DEB.2.02.1603041334290.31096@uplift.swm.pp.se> <B1328946-34AD-4222-813E-3B7A67B5B6CA@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1600216210-1459688408=:31096"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/fdXVS6ZjcXqxTb-Fqb6bO3uOzLc>
Cc: mif@ietf.org
Subject: Re: [mif] next step for MIF PVD configuration
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Apr 2016 13:00:12 -0000

On Sat, 12 Mar 2016, Margaret Cullen wrote:

>
> Hi Mikael,
>
> I agree with some of the issues you have raised about the current draft for DNS lookups of PVD information.  I think that if we go with a DNS-based approach, we will need to do some work on the DNS mechanism to fix these sorts of issues.
>
> Do you have time to write a draft for the mechanism you have suggested, so that we can discuss it in the group?

Hi,

as you might have dedicted, I did not do this.

In talk about other issues with Ole Tröan, he suggested RFC4620 "IPv6 Node 
Information Queries" as a potential mechanism that could be augmented for 
sharing all kinds of information between nodes. I just read this and it 
could be used, but I don't have a firm opinion yet exactly how it should 
be formatted, how to do indirection (if needed).

I feel we need to understand the deployment model better, we need to 
decide who should have access to what information (if we put it in DNS, 
should anyone on the Internet have access to the speed of the Internet 
connection and if it's metered or not? There are pros and cons with both 
making it secret or not).

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