Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple Provisioning Domain Architecture) to Informational RFC

Dmitry Anipko <dmitry.anipko@gmail.com> Thu, 05 February 2015 04:25 UTC

Return-Path: <dmitry.anipko@gmail.com>
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 01FD71A1A09; Wed, 4 Feb 2015 20:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 b805_vnfPeH4; Wed, 4 Feb 2015 20:25:27 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4F01A0210; Wed, 4 Feb 2015 20:25:10 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id h11so7926397wiw.1; Wed, 04 Feb 2015 20:25:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AKPsxCZ72IVyhbd5COOqUIGcxy5313uxg98dvTkjIag=; b=OfUKjxSk36+byySOxDoVHVDfy/iiUedEHKF1atW9Pk6xcZOFV5yQn8GrQ/q4GkZzP3 0WC7b9PAEMIcm+9L286xBQTVeueIJwZKW6SwLo5tRn7UTGc4imIrqQy14V/rR8Q3gW6r AS+GVsz0+Nl48GqwSD0FyHmizOiL+F3Yr7b9nRCusieGNiLVNa4YF03TDrRlNgBRj8X3 pan6ftoBYFE7/EYB/56+UGqx2b8XWkkH/QZ4iaJwpgqH6euBF3WQr+lqOWagnRSPCNsy 0QurlNntNjQdqbKG7Qix6TE9GQxrXbYpZ6lpNlFomUue430GGZx5xiDezMzk3Fu8qVU7 ETsA==
MIME-Version: 1.0
X-Received: by 10.180.205.210 with SMTP id li18mr6751453wic.39.1423110309660; Wed, 04 Feb 2015 20:25:09 -0800 (PST)
Received: by 10.180.209.38 with HTTP; Wed, 4 Feb 2015 20:25:09 -0800 (PST)
In-Reply-To: <FBE72B61-28E1-456B-BF3C-1B6C9C4A7D38@nominum.com>
References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> <A48A040C-F8C3-4E97-AF97-CD80DD19C3CD@iki.fi> <ECA36B14-039B-4842-B492-632E8FC5F0C5@nominum.com> <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi> <FBE72B61-28E1-456B-BF3C-1B6C9C4A7D38@nominum.com>
Date: Wed, 04 Feb 2015 20:25:09 -0800
Message-ID: <CACurXJgeCgLuAJOaxtO47Uh_osgk7WsP-1F-h0VvO5kL+xZxqA@mail.gmail.com>
From: Dmitry Anipko <dmitry.anipko@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: multipart/alternative; boundary="001a11c260ec7bcd32050e4fb0da"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/D2PU6fD-3k-8fggyqWvsGgSNRWE>
Cc: Markus Stenberg <markus.stenberg@iki.fi>, "mif@ietf.org List" <mif@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple Provisioning Domain Architecture) to Informational RFC
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: <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, 05 Feb 2015 04:25:31 -0000

My reading is that there is a consensus to fix the name misspelling :-),
but I could not quite read whether the PKI question got resolved. Markus,
can you please comment whether the modification Ted worded would address
your concern?

On Tue, Feb 3, 2015 at 10:26 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> On Feb 3, 2015, at 9:09 AM, Markus Stenberg <markus.stenberg@iki.fi>
> wrote:
> > Fair enough; I guess just splitting the dual stack PVDs if encountered
> (IPv4+IPv6 -> NATted IPv4 + IPv6 as-is) is sufficient answer to that. As I
> personally consider authentication mostly bogus, this is not really a
> problem for me :)
>
> To be clear, the authentication we're talking about here, at least
> generally, is not intended to assert that the node receiving it can trust
> it without question.   It merely asserts that the information came from a
> particular source, which the node may or may not trust.   That's what the
> text you were commenting on was for, actually.
>
> > So final suggestion - get rid of DANE, get rid of TLS, and probably
> rework the text in that paragraph a bit to make it simpler. As-is, both
> DANE and TLS mention seem superfluous.
>
> I'm skeptical about this--I think it's good to mention DANE.   DNSSEC is
> in effect a PKI, but it's quite a bit different than the other common PKI
> example.   How about "a PKI, for example DNSSEC/DANE or X.509?"   That way
> we don't lose the mention of DNSSEC, but keep it open to other PKIs.
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>