>>> reconfiguration - how does a device with an existing configuration
>>> update it? When / where / why / how?
>>
>> Why is this step different than configuration?
> I put that in, in part because of EAP-CREDS. In part because I'm not
> sure that updates fall within the bounds of provisioning / onboarding.
> i.e. I already have something, and I can get onto the network. How
> often do I refresh those credentials? What happens if my authorization
> changes? How do I get told if my credentials are withdrawn?
I understand.
For mechanisms like BRSKI (and CSP/MATTER, and probably UPC UA) where the end
product of onboarding is a certificate issued to the device, then the
question about when to refresh is mostly given by the notAfter parameter.
In most cases one should start refreshing those credentials at the 50% mark.
The ACME WG is discussing having the certificate renew point be better
specified (in the ACME protocol), but I think that we will learn from this
and wind up with something in the certificate if the protocol can't carry
additional meta-data.
> Perhaps this could better be described as policies and signalling for
> refresh and updates of provisioned data. The act of doing the update
> is just provisioning. Knowing when / where / how / why to do that
> update isn't quite part of the provisioning process.
Agreed.
There are advantages of having renewals spread across time, but there are
also disadvantages as it spreads the failure signal across time as well which
makes it harder to see that there is a real problem.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
