Btw:
As just posted, i restructured acp-15 so that section 10 is now only what i
call operational aspects, mostly about registrar behavior. Which does
apply to any type of registrar mostly. BRSKI or not. Based on review/discuss
with Joel. Just small bits specific to BRSKI.
The more difficult part is that some of this behavior needs to be standardized.
Thats the pieces i added to the normative sections. Such as "registrars MUST
NOT
allocate conflicting ACP addresses" (*doh*, but about the single most important
requirement
for the ACP ). Likewise interop is affected by how ACP nodes signal when
certs expire or fail. Added to certificate maintenance section.
I would be happy if i could offload all the operational aspects of the
ACP into a separate operational RFC for ACP, especially if it could help
to speed up getting this ACP draft out as an RFC (and make it shorter ;-).
Alas i fear that some @$$^%*& IETF reviewer will not allow us to make such
a new operational draft be an informational-only reference in the current
ACP draft, and that would just have us achieve the opposite of what we
need right now: Get the current ACP draft out.
So, and here i can not distinguish my ACP author and WG chair head:
unless some AD tells me how an ACP ops draft could NOT become a normative
reference to the current ACP draft, i will push back against opening
up one now (unfortunately).o
Cheers
toerless
On Tue, May 29, 2018 at 02:43:41PM -0400, Michael Richardson wrote:
>
> Some private discussion has suggested that there is a need for a document on
> operational issues (specifically security and PKI) for managing an ACP.
> While in theory everything should be autonomous, the exceptional situations
> and the multitude of options of how to deal with them will eventually need
> some clarification, if only so that they are automated correctly.
>
> This is just a note for later on; I think we need some operating ACPs before
> we can describe issues with them.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks
> [
> ] Michael Richardson, Sandelman Software Works | network architect
> [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
> [
>
>
>
> _______________________________________________
> 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
