Re: [mif] New Charter Items

Margaret Wasserman <> Sun, 13 March 2016 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5589712D5D7 for <>; Sat, 12 Mar 2016 16:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5DQt6jAm28Ez for <>; Sat, 12 Mar 2016 16:23:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E934612D59C for <>; Sat, 12 Mar 2016 16:14:21 -0800 (PST)
Received: by with SMTP id g127so130345727ywf.2 for <>; Sat, 12 Mar 2016 16:14:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i3aGoioKgwrbCRV65T3baoU8IJcKzs8WIIPMUfi8rp8=; b=wxAY9/qy5NyzGFV/BQx5DWvvYp6xIAoA5nUUzY6L4Waa533uH7XdtbWVCx/WDovTK8 SsotaUmrjp89VrquK5MIu4e6iIMhm7LA52AZU1xdbbWNODSP7bLV7yG4cNlpW4hdMauW JXtxIAw1bsorVzIN7yURy1rtqPhg1UESRZ+epDZ7Hyqt/YNhAPv950FfUjbYQlo0aIc1 rNRCpS+qi9oZe7Zw8hYl8nZkYsO50foyDINcdiRSQygbo0pPzsZW6ZtwlwwglO3KLvHg bKnjfAcZIx1EhzsleZIAO3NjnPc4tk9co5d9E/o5KtlX5esxF6oAK0lRU0SR+4fA0q2Z szqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i3aGoioKgwrbCRV65T3baoU8IJcKzs8WIIPMUfi8rp8=; b=PJetlQHmZkbDO5U65f76nBThdF8von0UwKQdNmZrxym8oL4zDkW7jcK7NnAeGIoZPZ aGyKdvKudqk7Mz7SCsFYu9RcUF8IrgaP49hXQvlammh2J8K9C/steGtKovouRQZ3IwUh rMKpGdM6Ot/wRpv8hVG6NaTFLpAUoHj5cdoulmbyFTSfz+xn/RSyXfQnLOeOygmGBoaq d0vri4cufn9C/Gr+A0za+zlYu/4ZRqDzLH5XXrIO4sO90J4FDVDh1g12cBusH1G1Cxsj coSwRUBjs3wZvhhydeQTzM5SEgF5XGy+RN7n0fRzlNq6AhCR3hmc8yAyLzWP+EBFYnPB popg==
X-Gm-Message-State: AD7BkJK9jp/mPuDA9NJxLd+WcQciO/4n1Q7lyf0kM9ollvDo6u2PHir8Hhg1g4pMyFLSHw==
X-Received: by with SMTP id b8mr7842948ybb.17.1457828061210; Sat, 12 Mar 2016 16:14:21 -0800 (PST)
Received: from new-host.home ( []) by with ESMTPSA id p63sm9876152ywf.8.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 12 Mar 2016 16:14:19 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Margaret Wasserman <>
In-Reply-To: <>
Date: Sat, 12 Mar 2016 19:14:18 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Jouni Korhonen <>
X-Mailer: Apple Mail (2.1510)
Archived-At: <>
Cc: " List" <>
Subject: Re: [mif] New Charter Items
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Mar 2016 00:23:45 -0000

On Mar 2, 2016, at 6:42 PM, Jouni Korhonen <>; wrote:
>> - An NTP server option for RAs, so that DNSSEC can be used for the lookup.
>> - A PVD Name option for RAs, so that we can tell hosts what PVD to look up.
> I thought we already got a WG I-D that is able to carry required name information if needed - maybe not in the "format" at the moment folks want it to be but it is up to WG to steer the content, right?


>> - What PVD information can be stored in the DNS and how it will be retrieved.
> While DNS is a good thing and actually a good idea in the context we are discussing here, few things to think in addition to those already found in the meeting minutes: does not quite work if DNS is not there and going to DNS all time even for the simplies form of PVD configuration seems a bit unefficient. These are not really concern of homenet type setups but maybe for other deployments where links come and go.

This mechanism would not be used for implicit PVDs (which I think have at least 80% of the benefit of explicit ones), only for explicit PVDs, and perhaps only for explicit PVDs that have a flag set saying that hosts should seek more information (?).  Presumably, if a host could not reach the DNS to find additional information about an explicit PVD, it would treat the PVD like an implicit one.  

I think it is a question for any two-step method, what to do if the first step configures and explicit PVD, but the second step can't be completed and/or returns an error?