So...
Welcome to the wonderful world of structuring our documents to
meet the intent of our charter ;-))
IMHO, we should mention GACP in one sentence of the ACP spec where
stable-connectivity is mentioned:
"The ACP was designed to meets the constraints/functionality specified
in [stable-connectivity] section 1.3, so it is a GACP in that documents
terminology and can therefore support the stable-connectivity
use case with all the considerations discussed in that document."
I'd prefer to fix that sentence during IESG review, not wanting to shoot of
another rev, but i'll let the the independent co-chair decide.
The same type of language would IMHO be true for future docs defining variations
of an ACP. Such variations would have to explain deltas if/where they exist.
[ And redefine how they provide transport/security for GRASP as Brian
mentioned. ]
I see no other place in current documents where we would want to use the
term GACP. The reference model specifically does not even refer to
stable-connectivity
because at it's core it is a non-AN use case, and the reference model is
ONLY about AN.
Just reviewing BRSKI, but don't think GACP should be mentioned there.
IMHO we want to need to have a sentence there with a simple, broader statement
about applicability of
BRSKI beyond ACP to any type of network infra, as long as you figure out how
start
proxies and have then know about registrar(s). That expectations not defined
in stable-connectivity at all.
Cheers
toerless
On Fri, Jan 19, 2018 at 08:06:16AM +1300, Brian E Carpenter wrote:
> On 19/01/2018 06:34, Michael Richardson wrote:
> >
> > Toerless Eckert <t...@cs.fau.de> wrote:
> > > I just posted -08:
> > > https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-08.txt
> >
> > > I have modified the verbage in -08 according to your suggestions.
> >
> > > A) GACP
> >
> > > Section 1.3 now introduces the four core design constraints of a
> > > generic ACP (GACP) (VRF isolation, IPv6 only, NOC connectivity and
> > > Group Security) which are the basis for the (existing/unchanged)
> > > discussion in the document.
> >
> > > The rest of the document has no semantic/content changes just textual
> > > changes for ACP -> GACP. There are two places where the text still
> > > refers to ACP specific examples and that is accordingly highlighted.
> >
> > Does that change ACP->GACP have to go across all documents?
>
> I don't think so. This does relate to one of the changes made to the GRASP
> draft after IESG review, where we made it clear that *the* ACP was the
> preferred substrate, but not the only possible substrate:
>
> A GRASP implementation will be part of the Autonomic Networking
> Infrastructure (ANI) in an autonomic node, which must also provide an
> appropriate security environment. In accordance with
> [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic
> Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane].
> ...
> GRASP does not specify transport security because it is meant to be
> adapted to different environments. Every solution adopting GRASP
> MUST specify a security and transport substrate used by GRASP in that
> solution.
>
> I don't think the "GACP" is any different, it's just a shorthand for the
> same point. (Probably we should also mention "GACP" in the reference model
> for consistency.)
>
> Brian
>
> >
> > Could you:
> > s/ 1.3. Leveraging a generalized autonomic control plane
> > / 1.3. Leveraging a generalized autonomic control plane (GACP)/g
> > ?
> >
> > I think not, as I understand Alvaro's comments:
> >
> > >> Hmmm???. I see your point, but that is not what the document says.
> > >> Not only does it specifically point at the ACP anima draft ("ACP as
> > >> defined in [I-D.ietf-anima-autonomic-control-plane]???), but it is
> > >> hard to ignore the work done in the WG.
> > >>
> > >> I think that if you clearly explained the characterization of *an
> > >> autonomic control plane* and mention *the ACP*
> > >> [I-D.ietf-anima-autonomic-control-plane] as an example of that, then
> > >> we would be ok. Please then also call it something else (GACP =
> > >> Generic/Generalized, or anything else that clearly makes people think
> > >> you???re not explicitly talking about *the ACP*).
> >
> > --
> > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
