Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt

"Michael H. Behringer" <michael.h.behringer@gmail.com> Tue, 30 June 2020 06:27 UTC

Return-Path: <michael.h.behringer@gmail.com>
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 51CF13A0B5F for <anima@ietfa.amsl.com>; Mon, 29 Jun 2020 23:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jwqddxojbPRD for <anima@ietfa.amsl.com>; Mon, 29 Jun 2020 23:27:17 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 A5BBB3A0B5D for <anima@ietf.org>; Mon, 29 Jun 2020 23:27:17 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id f18so10817498wrs.0 for <anima@ietf.org>; Mon, 29 Jun 2020 23:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=3X86dhrLylX3ESAizyyzWIjPdFs15DKUBKNYzybp1g4=; b=bfYxeHK39J/ZuMx+mA50Jz0olLtUEoqw/9hQY57GH6zg7eRszLC6B1ExgqtN8OmI++ SuAnkeHeQKFax4d+W8stZ0IzAqJmM1QdE5BBt/KWxIOwowPnTTymFisCZC655VtM+siD LfKZpSVNfjF0w26Msu3xKXPp7D0N/4iiaRzlO6K7aGR3ygt1UJEbvfWN1CS+fbL45x/e 40CXcHt6UMPRSADqI7inBkcHcXxtwcF6TurfO6oSkVgLehRas+R3RFe3qGO//EhBfZfh Ygtz463tko/wc9KmFCLVmNCqo6d/Zkoxz9XuyTz2+Dim/Fgl+eihr1t3RXXB0SA2yoL/ SGMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=3X86dhrLylX3ESAizyyzWIjPdFs15DKUBKNYzybp1g4=; b=O2GTXA5dcNrzq68OSZkCWa2/kuW2KeJjvzpyvt60WVHu6/kaXF81sEsqBBVeq+aYqq sG+zNcwSEU92cllKOfvOquGcfobz9uuve/HluQSIOhcpg6J84vpxWNKpfjrqja4jnSMV 1Pp7pfFOO3jCl/KGFHZVLWLsmrVymYUp2sBCsu+c4VP5ARNFZmbX7cRTDQwzI8Jj48q9 q8pWXWLMcUx+50Dqlnc5pRiDFxtwxbpN4eyePObMECPahCxTMG9HdbFKUFbnW6qSArCN +Lr9VuJUva0j5NWhiz5x4kugRonjyfYNEUAXWSFDm60M6RMk/3tJERfdpXSbNzmeXZ2p hNyQ==
X-Gm-Message-State: AOAM532fdMm0orbcF9UdNP6Z6XXYBVyrv7WxdPrYjQxTBFgldEJs6gyw agL72BSSj9dv5ehx92mE7m57Wxh/
X-Google-Smtp-Source: ABdhPJzqMl8eJF7s0RC/8WuyAz+huQApH6AYHqqePIyo46kGj5wnbiBW5G+cPlA0S6mnfFuRlBBrZA==
X-Received: by 2002:adf:e948:: with SMTP id m8mr20834313wrn.398.1593498435602; Mon, 29 Jun 2020 23:27:15 -0700 (PDT)
Received: from ?IPv6:2a01:cb1d:111:eb00:1435:bf0f:6f62:1e20? ([2a01:cb1d:111:eb00:1435:bf0f:6f62:1e20]) by smtp.gmail.com with ESMTPSA id l14sm2413462wrn.18.2020.06.29.23.27.14 for <anima@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2020 23:27:14 -0700 (PDT)
From: "Michael H. Behringer" <michael.h.behringer@gmail.com>
X-Google-Original-From: "Michael H. Behringer" <Michael.H.Behringer@gmail.com>
To: anima@ietf.org
References: <159296586835.337.577109779817720457@ietfa.amsl.com> <16876f80-5504-a622-f13c-686ce69b4733@sandelman.ca> <86736d02-d1b6-ebfb-a894-92c9ca4b1e96@concordia.ca> <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com>
Message-ID: <3528e4d5-4eb8-0e9f-6fe1-49494e9fcd54@gmail.com>
Date: Tue, 30 Jun 2020 08:27:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <1d463beb-ba42-9495-0c53-58116b6f3a57@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/rEPO3eGDHx6XD22ToW1x1kNlEB4>
Subject: Re: [Anima] "virtual out-of-band" ... or some minor non-ACP-number comments on Action: draft-ietf-anima-autonomic-control-plane-25.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 30 Jun 2020 06:27:19 -0000

I still prefer the definition "virtual out of band".

An "overlay" (secure or not) depends on correct configuration of the 
underlay. The ACP does NOT depend on configuration in the underlay, that 
is what makes it special.

I haven't seen the definition "virtual out of band" anywhere else, and 
it is the most precise way to describe it.

Michael

On 30/06/2020 00:06, Brian E Carpenter wrote:
> Say "secure overlay" to emphasise the point, but yes.
>
> The draft I submitted yesterday "describes a simple method of forming an ACP immediately above the transport layer" which is indeed precisely a secure overlay.
>
> Regards
>     Brian
>
> On 30-Jun-20 00:45, William Atwood wrote:
>> Is "overlay" the right word?
>>
>> I agree that it is physically in-band, and virtually out-of-band.  Isn't
>> that the definition of "overlay"?
>>
>>    Bill
>>
>> On 2020-06-28 11:02 p.m., Michael Richardson wrote:
>>> Attention This email originates from outside the concordia.ca domain. //
>>> Ce courriel provient de l'exterieur du domaine de concordia.ca
>>> On 2020-06-23 10:31 p.m., internet-drafts@ietf.org wrote:
>>>> A diff from the previous version is available at:
>>>>
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25
>>>
>>>
>>> yes, I read the diffs :-)
>>>
>>> -   This document describes a modular design for a self-forming, self-
>>> -   managing and self-protecting ACP, which is a virtual in-band network
>>> -   designed to be as independent as possible of configuration,
>>>
>>> +   This document describes a modular design for a self-forming, self-
>>> +   managing and self-protecting ACP, which is a virtual out-of-band
>>> +   network designed to be as independent as possible of configuration,
>>>
>>> This change from being a virtual in-band network to a virtual
>>> out-of-band network must have been in response to some comments... It
>>> seems a big change in some ways.  I guess it makes this text consistent
>>> with the abstract which has said virtual out-of-band for awhile now.
>>>
>>> But, I do have to wonder if we are creating confusion by claiming that
>>> this is an out-of-band mechanism, even though it's really an in-band
>>> mechanism.  It's just virtually-out.
>>>
>>> I actually do want to start a bike-shed issue here?
>>> Are we describing ourself wrong?  Maybe there is some portmanteau that
>>> would be more accurate?  I think that the above sentence is essentially
>>> the elevator pitch for all of ANIMA.
>>>
>>>
>>> There is also a bunch of other text that has been added to the
>>> Introduction, which I think confuses more than it enlightens.
>>> Or at least needs a better copy-edit.
>>>
>>> A number of other new sections (9.4..) need a copy-edit to fix some
>>> missing words.  I will try to help Toerless with that via github.
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima