Re: [Anima] [6tisch] [Netconf] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017

peter van der Stok <stokcons@xs4all.nl> Mon, 21 August 2017 07:37 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B734113291F; Mon, 21 Aug 2017 00:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qs8YItuFIbDd; Mon, 21 Aug 2017 00:37:01 -0700 (PDT)
Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 96E12132926; Mon, 21 Aug 2017 00:37:00 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:211]) by smtp-cloud9.xs4all.net with ESMTPA id jhGadHPCLdRLjjhGadi5Yz; Mon, 21 Aug 2017 09:36:58 +0200
Received: from ip565c6c1e.direct-adsl.nl ([86.92.108.30]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 21 Aug 2017 09:36:55 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Mon, 21 Aug 2017 09:36:55 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Kent Watsen <kwatsen@juniper.net>
Cc: consultancy@vanderstok.org, anima-chairs@ietf.org, 6tisch@ietf.org, netconf@ietf.org, anima@ietf.org, Sheng Jiang <jiangsheng@huawei.com>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <8168023A-AC1F-4A7E-B8BA-026651EFEF33@juniper.net>
References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net> <1fee7f82c855def7345d506fbb720dbc@xs4all.nl> <8168023A-AC1F-4A7E-B8BA-026651EFEF33@juniper.net>
Message-ID: <d508d9834764e62af74957e3224430b9@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfKVxOchUAcQPO0lWmeROLpqCYU1XK6J4PVreOUm4jbZpUXdmglHiAY9oXaQEPJtSYmg93cLy3H2qEHs0pSH7oEw32FQlsO+aLrmo9mrk9SjuJmuL+qsZ Eiftn2NTfweBEXwHCN6epIYiT+uZprCOd/C1BX/IxkotfZpRn7zdufarhJHQhWdhl8+eFSVfut+DprQcmr7wIgYWmyYj4fvHtNBw1HbIyAZlDFfAxpwOC5U7 e+2FpQoZnuWLgY2fMwj3yASPQytxyLf+LGOW+fzKsEwvpV5Ybjtj0Di2D9H/KlH/zvUfOb0trVMAa9YB3rs3K/aKjm2INOIP1i9StzGEv8NJ/TVy3rzusyWv INzLHI+q8bAY/f+MhxPS3KIMDwS8G46ZR/jaMpR7hNnoD/UueAztB4HCNnDqfYBlLkx1E9vE
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/nlsrtv_QhKKEXjpoCgtZ_sh2EjU>
Subject: Re: [Anima] [6tisch] [Netconf] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Aug 2017 07:37:04 -0000

Hi Kent,

>>> Can a discussion section about "manufacturer additions" be
>>> added. Pointing out the consequences for interoperability
>>> when using "Augment" to add manufacturer specifics can be
>>> helpful.
>> 
>> I'm confused, which section does this comment regard?
> 
> It refers to the document as a whole and especially section 7.
> Usually, manufacturers want manufacturer-specific additions to
> documents.
> They may consider to use Augment for that purpose.
> My suggestion is to discuss ways to add manufacturer additions to the
> voucher and the consequences.
> That may turn out to be a big NO-NO to manufacturer additions.
> I think it would be worthwhile to point that out.
> 
> <KENT> Are you asking for the voucher to contain a node
> called something like 'opaque' having YANG type 'anyData'?
> A sanctioned place where the MASA can stash some extra
> stuff not defined by this document?  Recall that some of
> the motivation for this work being standardized is to
> enable inspection by intermediates, and while the opaque
> data could be presented to a human, it might be base64
> data.  Any concerns bout that?

<pvds>
My suggestion is a discussion not a standardization. So, no additions to 
the voucher in this document.
However, pointing out the base64 format would be helpful for those 
thinking about an addition with opaque.
</pvds>
> 
>> page 4, Voucher: add: that "acknowledges ownership of the pledge and"
>> indicates...
>> 
>> <KENT> what does "acknowledges ownership of the pledge" mean?  how
>> is it different than "indicates to a Pledge the cryptographic identity
>> of the Domain it should trust"?
> 
> Now I am confused. I thought it was 2 ways. Pledge trusts domain, and
> domain partners trust pledge.
> 
> <KENT> The pledge trusts the MASA (which signs the voucher) and then
> the pledge trusts the domain (whose cert is inside the voucher).
> Perhaps you're conflating signing the voucher with acknowledging
> ownership?

<pvds>
I am afraid, that I made the voucher responsible for all keyinfra 
protocol objectives.
Sorry, for the confusion.
</pvds>
> 
>