Brian, Michael: For the purpose of BRSKI the only relevant aspect of the
ANI is that it is assumed to be a system that support BRSKI and ACP,
and then the document starts to define a bunch of requirements against
BRSKI, which instead of saying ANI could equally say "BRSKI devices that
also support ACP". So BRSKi really does not need to try to refer to a
complete definition of ANI or attempt one by itself, but rather clarify
the relationship to ANI that is used in the BRSKI document.
To maintain the independence of BRSKI from unnecessary normative
references, maybe something like the following:
<t hangText="ANI:">The Autonomic Network Infrastructure consists
of devices supporting both BRSKI and <xref
target="I.D.ietf-anima-autonomic-control-plane"> (ACP).
In ANI devices, BRSKI relies ACP to connect BRSKI Registrar and
BRSKI Proxies.</t>
Not sure what value a reference to the reference model would have here in this
terminology.
Cheers
Toerless
On Wed, Jun 20, 2018 at 08:27:04AM +1200, Brian E Carpenter wrote:
> On 20/06/2018 03:38, Michael Richardson wrote:
> > On 31/05/18 04:23 PM, Brian E Carpenter wrote:
> >> On 01/06/2018 07:31, Michael Richardson wrote:
> >>>
> >>> Toerless Eckert <[email protected]> wrote:
> >>> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote:
> >>> >> > I would prefer to have the simple definition "ANI == systems
> >>> that support
> >>> >> > both BRSKI and ACP" in the doc itself. Threre is really no
> >>> single authoritative
> >>> >> > normative document for ANI, so it should simply be stated
> >>> equally in BRSKI and
> >>> >> > ACP. Rest of text is fine.
> >>> >>
> >>> >> I'm not getting what you are suggesting.
> >>> >> I think you are saying that we shouldn't point at ACP for the ANI
> >>> term, but
> >>> >> rather define it ourselves?
> >>>
> >>> > Yes.
> >>>
> >>> okay, I've copied text:
> >>>
> >>> ANI: "Autonomic Network Infrastructure". The ANI is the
> >>> infrastructure to enable Autonomic Networks. It includes ACP,
> >>> BRSKI and GRASP. Every Autonomic Network includes the ANI,
> >>> but not every ANI network needs to include autonomic functions
> >>> beyond the ANI (nor intent). An ANI network without further
> >>> autonomic functions can for example support secure zero touch
> >>> bootstrap
> >>> and stable connectivity for SDN networks - see
> >>> [I-D.ietf-anima-stable-connectivity]
> >>>
> >>
> >> Wrong answer, IMHO.
> >>
> >> draft-ietf-anima-reference-model defines the ANI at some length.
> >> That should be the (informative) reference for basic terminology.
> >
> > I think that you'd like us to change the text to say:
> >
> > <t hangText="ANI:">The Autonomic Network Infrastructure as
> > defined by <xref target="I-D.ietf-anima-reference-model" />.
> > This document details specific requirements for pledges,
> > proxies and registrars when they are part of an ANI.</t>
> >
> > is this correct? Or did you want us to retain some other words above?
> >
>
> Personally, I'm happy with the reference (and with it being informational).
> Duplication of definitions always creates a risk of confusion.
>
> Brian
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
