Benjamin Kaduk <ka...@mit.edu> wrote:
>> John Mattsson <john.matts...@ericsson.com> wrote: > of negotiation is
>> still needed. The current plan for the next version > is to introduce
>> cipher suites and to let the cipher suite with value 0 > indicate that
>> algorithms have been negotiated out-of-band.
>>
>> I agree with the idea that some common default should be very easy to
>> refer to, but I don't like the idea that the gateway has to remember
>> what the out-of-band "default" is on a per-device basis. I would say
>> that we need at least 0/1, so that we can say that it's the current vs
>> the "new" default.
>>
>> If you consider the case where the sensor is on very low bandwidth
>> connection (I would say LoRaWAN, but I am not well qualified in that
>> space). The sensor gets visited every two or three years by a
>> technician (if only to make sure that the sensor is still where it is
>> supposed to be). While there new firmware updates are applied, and as
>> a result the algorithm defaults are updated. During the cycle, some
>> devices are updated and some are still old.
> 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.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
