Hi Michael,
To be clear, I don't feel at all strongly about this. If people accept
'virtual out of band', I certainly don't object.

Regards
    Brian
    (via tiny screen & keyboard)

On Tue, 30 Jun 2020, 18:27 Michael H. Behringer, <
michael.h.behrin...@gmail.com> wrote:

> 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-dra...@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
>
> _______________________________________________
> 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

Reply via email to