Roman Danyliw via Datatracker <nore...@ietf.org> wrote:
> (3) Why is Section 7.x in this document if it explains how to use BRSKI
> but is
> considered non-normative?
> -- How should implementers take this language?
> -- Why are normative sections, like Section 11, discussing it?
1) It's non-normative for proper/full operation of the ANIMA ACP
2) We think that some of the mechanisms that 7.2 describes may be needed
in order for operators to have ways to work around infrastructure
failures, such as manufacturers going out of business.
We don't want to standardize
I see that we use 2119 language in this section, and maybe that
does not belong. or maybe the section should be normative, but
consist of a series of "MAY" statements?
If vendors are going to provide work arounds ("back-doors")
it would be best if they did something we can identify and reason about.
So to use the back-door to the building analogy: we want to define
fire-exits in the building code rather that doors that are insecure.
A lot of the text in Section 7 was originally sprinkled elsewhere, but that
confused things. As shown by the long thread from concerned operators,
this move towards a secure-onboarding-by-default scares people who
are used to improvising things in an emergency.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
