Benjamin Kaduk <[email protected]> wrote: >> > Are you proposing that the management of the 0/1-to-algorithm mapping >> > be managed on a per-deployment basis or by the IETF? >> >> I think that the existing proposal was that 0 means "negotiated out-of-band", >> which implies that it's a per-deployment basis. >> >> I'm proposing that instead of having 0 mean "some local default", >> I'm suggesting that 0 mean, "some local default 0" and 1 mean, "some other >> local default 1", which lets the default be updated without a flag day.
> That feels like a potentially awkward provisioning problem. I guess the
> idea is that any given node is only going to do 1 or 0 and not both?
Maybe
> that helps.
I don't think you get it if you think it's awkward!
Any firmware implements 0 or 1, correct.
[I'm not a fan of such a system. I also don't think it is small enough for
LoRAWAN either]
When a new choice is hard coded into that closed vertical system (via
"out-of-band"), this choice would be baked in at the next firmware update.
(There are many ways to do this of course. Throw dip switches if you like)
Having both 0 and 1 lets the firmware be incrementally updated, otherwise the
operator either has a flag day, or has to keep track of the parameters on an
per-device basis.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
