Re: [Gen-art] Genart last call review of draft-ietf-anima-reference-model-06

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 10 August 2018 16:16 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE82130E8F; Fri, 10 Aug 2018 09:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 5eAJ8tlmsWPq; Fri, 10 Aug 2018 09:16:56 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 EE02F130E68; Fri, 10 Aug 2018 09:16:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DD3CB9C098A; Fri, 10 Aug 2018 09:16:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1533917815; bh=ZIffEPtutCYLsU/VRHcTY/Titykrngl8aF6ywDtN3ZM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=iwliC1NJJSPlVzhj9eDX6mPSLPHE1/HT1E9Bse6P33qb/rCpfNEns+eZfT/vgx63Z u7k/wupA7YVCW8MrB1aT1rHnqfaNA4Xv+KJth22EaJT0QNDn79zrX1mHCCz/aeOqlj wGEK9PBP7FaSw+TthJ8X/I/Xc8+hhWAnTN92GWXk=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 043629C06C5; Fri, 10 Aug 2018 09:16:54 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>
Cc: gen-art@ietf.org, ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org
References: <153386283991.28744.9091243291268056328@ietfa.amsl.com> <20180810051018.ovgyku7jk4dwvzy2@faui48f.informatik.uni-erlangen.de> <c3a8350c-7b29-e0a3-b6f8-dcf2aa402fa4@joelhalpern.com> <20180810161228.kylkuaq4c3uddfc2@faui48f.informatik.uni-erlangen.de>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <6ffee0e8-c06a-a3e7-8f67-44a5f6c31837@joelhalpern.com>
Date: Fri, 10 Aug 2018 12:16:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180810161228.kylkuaq4c3uddfc2@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/AmPG5_I9DQmVfTtlzMERRx0mWQk>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-anima-reference-model-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2018 16:16:58 -0000

At this point I think we understand each other's points, and I will wait 
for Michael to comment as pen-holder.
Thank you for the prompt response and discussion.
Yours,
Joel

PS: While I sympathize with your reaction to paying for standards from 
other SDOs, that is not what determines whether we reference them, or 
whether those references are normative.  No mater how much we wish 
otherwise :-)


On 8/10/18 12:12 PM, Toerless Eckert wrote:
> On Fri, Aug 10, 2018 at 10:12:37AM -0400, Joel M. Halpern wrote:
>>> Imho, the reference model text is correct. Just like in the non-autonomic
>>> input (third bullet item), this vendor-redirect/cloud-registrar would
>>> lead to an automatically set up remote ACP peer thats enterred into the
>>> adjacency table.
>> <jmh>I can't find anything in the bootstrap document redirect section that
>> suggests the behavior you indicate.</jmh>
> 
> Thats true, the BRSKI documents defines key cryptographic aspects
> of a cloud registrar and there are a lot of options for a full solution,
> and the conclusion was to do these things as followup work from BRSKI / ACP.
> 
>>> Hmm.. ACP is an overlay network that tries to match the underlay when
>>> it can (link-local-adjacencies) and that uses remote adjacencies when
>>> it needs to go over non-autonomic parts of the network.
>>>
>>> Not quite sure what text to most easily add to make this any clearer..
>>> Any suggestions ?
>> <jmh>The text mixes both uses of adjacency without distinction.  One could
>> seaprate the usage.  One could add explanatory text.  Something to clarify
>> the situation. </jmH>
> 
> Hmm.. it does clearly distinguish the three cases through bullet
> points, each one describing one of the three cases. Maybe i'm
> just confused what you think is missing and Michael immediately sees it.
> 
>>> 802.1AR as already referenced by ACP
>> <jmh>My only concern is that it appears to need to be a normative reference
>> here, as it seems to be needed for understanding this document. </jmh>
> 
> I don't think its necessary to read 802.1AR to understand
> the security reason why its used. BRSKI does that explanation,
> and BRSKI is already normative. Personally, i dislike to have "pay-to-read"
> documents as normative references, as much as i do appreciate
> every SDOs need to finance itself.
> 
>>> The security model of nodes without writable persistent storage comes
>>> to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash
>>> only, power-cycle recreates known "good" state on device).
>>
>> <jmh>The text as written implicitly requires persistent storage.  If the
>> intention is to allow both models (as I would hope) please tune the text in
>> section 3.3.2.
> 
> Maybe a sentence at the end:
> 
> On devices without persistent storage for the LDevID, a powercycle
> should behave like a factory reset.
> 
>>> chair hat on:
>>> There can not be a draft covering this yet, because the current
>>> ANIMA charter didn't allow us to do this. We've got individual drafts
>>> lined up for this topic, we just need to get through the rechartering,
>>> we have started the discuss with our AD and wanted to then bring this to
>>> the WG.
>> <jmh>How can this informational documents say "ASA must ..." if there is no
>> definition of what they must do.  If the WG has not addressed this topic,
>> then reword this.  Maybe "It is expected that wide deployment in the future
>> will need ..." </jmh>
> 
> I think 6.1 is just missing the (*).
> 
> Cheers
>     Toerless
>