Re: [mif] next step for MIF PVD configuration
Mikael Abrahamsson <swmike@swm.pp.se> Fri, 04 March 2016 12:48 UTC
Return-Path: <swmike@swm.pp.se>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE0B1B37D0 for <mif@ietfa.amsl.com>; Fri, 4 Mar 2016 04:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.252
X-Spam-Level:
X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 hpO-r-gZXnti for <mif@ietfa.amsl.com>; Fri, 4 Mar 2016 04:48:17 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 1F05C1B37EF for <mif@ietf.org>; Fri, 4 Mar 2016 04:48:17 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id D1B50A2; Fri, 4 Mar 2016 13:48:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1457095694; bh=fYFW71xD5L2dTjUXlkxKdQm2fxj5/gG5boJUzE9aZBY=; h=Date:From:To:Subject:In-Reply-To:References:From; b=FEzgtbZvqTGaF0+Y/x60SWRtF1i8/GU4N1QoA1DRtA+zF6lny9hzAmF6WmKNF9PEo zBZb6Fz/i6MJJ9+l3rFOEl7+0rdr22J5EMYgkHkPs1bJ8Il7qEkuw+jIRvSrPT//xN oUvb6+f0Dh68IuofF15T1LPfd83vIAVdoiv7NMMU=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CE1D9A1 for <mif@ietf.org>; Fri, 4 Mar 2016 13:48:14 +0100 (CET)
Date: Fri, 04 Mar 2016 13:48:14 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: mif@ietf.org
In-Reply-To: <56D82434.5020803@fer.hr>
Message-ID: <alpine.DEB.2.02.1603041334290.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>
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-1602763439-1457095694=:31096"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/sGXVFpjq1ZL150_x-o5dLeN1ilw>
Subject: Re: [mif] next step for MIF PVD configuration
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 04 Mar 2016 12:48:19 -0000
On Thu, 3 Mar 2016, Stjepan Groš wrote: > Finally, obviously this solution assumes a single DNS server from one > ISP will provide all the data about PvDs. If you have two or more ISPs > and expect them to be collaborative is nice thing to hope for, but in > case they don't user is stuck. And even if they collaborate, that > neither scales nor is responsive. I re-read draft-stenberg-mif-mpvd-dns-00 . It's not obvious to me if the PvD information is globally available for anyone to ask (or not), or if there is a requirement for some kind of split horizon DNS view where you need to ask from an address within the PvD to actually get an answer back regarding the PvD. I have doubts about the DNS method, and I would prefer to have some kind of other mechanism to distribute the PvD information. What about having one more level of indirection (yeah, yeah, I know, RFC 1915 6a), and instead find the configuration resource via some kind of SRV record either available via DNSSD or via PTR .arpa lookup, or via DHCP option? Then the information could be fetched using HTTPS or some other mechanism. draft-ietf-netconf-zerotouch-04 uses these kinds of mechanisms to provide data, where you instead sign the configuration data that can be downloaded through insecure means, but you won't use it until you've verified its authenticity (for instance by doing lookups using DNSSEC to get certificate ID or similar). I also would like to separate the mechanism(s) how the information is transmitted and what information we want to transmit. These discussions are very different, and the mechanism how to transmit the information is probably not going to be changed that much, whereas we might want to add information we want to transmit more frequently. -- Mikael Abrahamsson email: swmike@swm.pp.se
- [mif] next step for MIF PVD configuration Hui Deng
- Re: [mif] next step for MIF PVD configuration Stjepan Groš
- Re: [mif] next step for MIF PVD configuration Margaret Cullen
- Re: [mif] next step for MIF PVD configuration Margaret Cullen
- Re: [mif] next step for MIF PVD configuration Stjepan Groš
- Re: [mif] next step for MIF PVD configuration Mikael Abrahamsson
- Re: [mif] next step for MIF PVD configuration Margaret Cullen
- Re: [mif] next step for MIF PVD configuration Mikael Abrahamsson
- Re: [mif] next step for MIF PVD configuration Mikael Abrahamsson
- Re: [mif] next step for MIF PVD configuration Ted Lemon