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> Fri, 18 August 2017 07:45 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 995B9132144; Fri, 18 Aug 2017 00:45:50 -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 OwcnWMbjCggX; Fri, 18 Aug 2017 00:45:48 -0700 (PDT)
Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (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 885BD12EC06; Fri, 18 Aug 2017 00:45:46 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud8.xs4all.net with ESMTPA id ibyRdFVTccQyLibyRdQQfr; Fri, 18 Aug 2017 09:45:45 +0200
Received: from ip565c6c1e.direct-adsl.nl ([86.92.108.30]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 18 Aug 2017 09:45:43 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 18 Aug 2017 09:45:43 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Kent Watsen <kwatsen@juniper.net>
Cc: consultancy@vanderstok.org, Sheng Jiang <jiangsheng@huawei.com>, anima-chairs@ietf.org, 6tisch@ietf.org, netconf@ietf.org, anima@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net>
References: <5D36713D8A4E7348A7E10DF7437A4B927CE3D826@NKGEML515-MBX.china.huawei.com> <76229c58f5d60d3a0c185c6645ba4355@xs4all.nl> <3F9D68E6-57C9-48EF-A4EB-3CA8B613D42D@juniper.net>
Message-ID: <1fee7f82c855def7345d506fbb720dbc@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfLvmp/uAoE0ESmd6fJb69jJaqfYQYNjthF/bPbChbMOo6X8V+92q4gysxaVLdSHZoAZqvJ97wIlO/F9kjiRCsQiKQleF/0ZxNZiFvcsxS97VTWtB8W76 WTs3UUTJ7YheaDrrY4M6R6o73ZQzr2XcHlw3PRGwhAcAfg3V3OCuf0OEEPhvtgoD+zwtkU+wy5AV+jTI9QyKGoam7c4ba3egyQCRnm8L60lB/TJ1PMLJmSLj Jddq95rAaCLF8dLy8K9x2Aq5aoNRLwF8AFhT8dHvC5x+TqmAxWsisRhZV47qEqCw2xktdar+nhBhxi+VG4W8dN7/g33Mgh7F5ngjSBaPXxnotz4+OwpOuw2g oWePRlq3
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/FbyD1m-AOqv9sAtruddr_QsjESM>
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: Fri, 18 Aug 2017 07:45:51 -0000

>> 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.


> Section 2; mention terminology from RFC7950
> 
> <KENT> What is this?  Are you asking for the draft to import terms
> from RFC7950?  Which terms

Reading RFC7950 is useful to understand section 4 for example; and 
needed when reading the voucher YANG text.
So not especially terms, but complete knowledge of RFC7950 is required.
> 
> 
> 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.


> 
>> Add type in:
>> Ownership ID voucher "type" is named
>> Bearer Voucher "type" is named
> 
> <KENT> you only mention these two, but none of the voucher type
> descriptions have "type" in them, or maybe I'm missing something.

The name of the voucher is taken from the type I understand.
Only ownership ID voucher and Bearer voucher have text starting with 
"xxxx is named".
I see that I forgot: An audit voucher "type" is named .....

> 

>> section 7.1 last line: "there is a delay" is that delay between 
>> creation
>> and consumption and when is the delay unacceptable? the text is (on
>> purpose?) vague.
> 
> <KENT> The previous sentence says "...there may be a significant
> delay between when a voucher is created and when it is consumed."
> and the remainder of the line you're citing says "to ensure that
> the assertions made when the voucher was created are still valid
> when it is consumed."   This is vague?

To me yes. It sounds like a circular definition.
To paraphrase: When the voucher is consumed, the assertions are valid by 
definition.
I would expect a pointer to a delay definition and then an assertion 
that states:
  when consumption time is larger than the creation time + delay, the 
voucher is invalid.
>