Re: [mif] Updated charter

Ted Lemon <ted.lemon@nominum.com> Thu, 10 October 2013 13:07 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 D73B021F90AF for <mif@ietfa.amsl.com>; Thu, 10 Oct 2013 06:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.602
X-Spam-Level:
X-Spam-Status: No, score=-106.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPzqpiToBZDN for <mif@ietfa.amsl.com>; Thu, 10 Oct 2013 06:07:13 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 15F1111E8166 for <mif@ietf.org>; Thu, 10 Oct 2013 06:06:06 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUlamNrkBWOjXJ+KYrYK3MysGmoQgmlcZ@postini.com; Thu, 10 Oct 2013 06:06:12 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 94F3C1B82EA for <mif@ietf.org>; Thu, 10 Oct 2013 06:05:56 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8C24E19005C; Thu, 10 Oct 2013 06:05:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Oct 2013 06:05:50 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <alpine.DEB.2.02.1310100517440.20065@uplift.swm.pp.se>
Date: Thu, 10 Oct 2013 09:05:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <A1182E15-656E-4108-A28A-5AA352226C61@nominum.com>
References: <CANF0JMCiHxXM4zb=t==0DT=P2FksyP3NPZ2x6YT6ViUDsg0J4w@mail.gmail.com> <alpine.DEB.2.02.1310100517440.20065@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: MIF Mailing List <mif@ietf.org>
Subject: Re: [mif] Updated charter
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 10 Oct 2013 13:07:34 -0000

On Oct 9, 2013, at 11:27 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> I read this proposed new charter. It contains DHCP and DNS items as it is right now, so I have a bit hard time understanding "will be removed"? I read the charter as it is posted on http://datatracker.ietf.org/wg/mif/charter/ and that one has a "1. dns server selection solution" that seems to have been removed, is that was the "will be removed" refers to?

The server selection document has been an RFC for a year or two now, and the router option really shouldn't have been a MIF work item to begin with, and caused a lot of trouble in the MIF working group before you arrived.   If we left it in in order to minimize changes, it would probably create more problems than it would avoid.

> I don't really understand this sentence. MIF could recommend new DHCP options, but nothing else? What if we feel a new RA option (for RFC6106 to work properly) or different behaviour of RA is warranted, is that out of scope? I feel this is quite a big limitation to put on ourselves. Perhaps wording such as "should try its hardest to find solutions that do not require changes to basic IP protocols" or something along those lines could steer work but not limit it? Or we just re-charter if we run into a dead-end and can't make it out unless we change something?

It should indeed mention RAs.   The point is that we don't assume that the host already has some way of dealing with the MIF problem, like a connection manager or something of that sort.   At least, I _think_ that's the point—Dmitry actually wrote that text, so he can probably explain better than I can.