Subject: [Anima] Factory reset: Do we need two types?

From: "Michael H. Behringer" <[email-masked]>
Date: Fri, 10 Mar 2017 11:45:07 +0100

There was a discussion about the term factory reset, and what it means. 
Specifically, whether the LDevID (domain certificate) is deleted.

The notes I have taken (from someone's mail) indicate:
   type 1: erase all but LDevID - Device doesn’t need to re-enrol
   type 2: erase all, including LDevID

While trying to work this into the reference draft, I'm getting less and 
less comfortable with the sentiment of "two types of factory re-set".

Here my thinking:
- Factory reset brings a device back to the state it had when it left 
the factory. This is very unambiguous, and clear. The device will keep 
its IDevID and the LDevID will be deleted. (may be worth noting in the 
reference draft though, to be sure).
- A process where the LDevID remains on the device in my view of the 
world is therefore NOT a factory reset. I would call this "erase device 
configuration except the LDevID".

I therefore suggest to use / define the term "factory reset" as per 
first bullet above. And NOT define two types of factory reset. It just 
feels wrong to me.

What am I missing? Why did we even need a term for the second? Can we 
not just say "delete config, but leave LDevID"?

Michael

---

From: "Beck, Stefan" <[email-masked]>
Date: Fri, 10 Mar 2017 12:05:41 +0000

I agree with Michael - only "type 2" should be termed as "factory reset".

"type 1" reads to me as: "Reset a device to its default settings, but keep it in the domain it was enrolled to".
This includes keeping the LDevID, but also other data such as the trust anchor(s).

Stevie

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Michael H. Behringer
Sent: Friday, March 10, 2017 11:45 AM
To: [email-masked]
Subject: [Anima] Factory reset: Do we need two types?

While trying to work this into the reference draft, I'm getting less and less comfortable with the sentiment of "two types of factory re-set".

Here my thinking:
- Factory reset brings a device back to the state it had when it left the factory. This is very unambiguous, and clear. The device will keep its IDevID and the LDevID will be deleted. (may be worth noting in the reference draft though, to be sure).
- A process where the LDevID remains on the device in my view of the world is therefore NOT a factory reset. I would call this "erase device configuration except the LDevID".

I therefore suggest to use / define the term "factory reset" as per first bullet above. And NOT define two types of factory reset. It just feels wrong to me.

What am I missing? Why did we even need a term for the second? Can we not just say "delete config, but leave LDevID"?

Michael

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Mar 2017 16:06:50 +0000

Also agree, factory reset only means one thing.

K.

-----Original Message-----

Stevie

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Michael H. Behringer
Sent: Friday, March 10, 2017 11:45 AM
To: [email-masked]
Subject: [Anima] Factory reset: Do we need two types?

Here my thinking:

Michael

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 10 Mar 2017 20:20:35 +0000

+2 (grin)

Factory reset means: back to what the factory shipped. No intermediate states.

(If there is actually a requirement for an intermediate state it can be developed as part of other/additional work. Such would not be called “factory reset” it would be something else). 

- max

> On Mar 10, 2017, at 9:06 AM, Kent Watsen <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Mar 2017 15:00:29 -0500

Michael H. Behringer <[email-masked]> wrote:
    > worth noting in the reference draft though, to be sure).  - A process
    > where the LDevID remains on the device in my view of the world is
    > therefore NOT a factory reset. I would call this "erase device

"Reset to default configuration"

    > first bullet above. And NOT define two types of factory reset. It just

I agree.

    > not just say "delete config, but leave LDevID"?

I think that this is the activity that one usually wants when some
button is held down.  Deleting the LDevID is probably more than most
operators expect.

Deleting the LDevID brings the device back to "unowned" state.
Some devices should support such a thing, and some simply should not.
Some should require a screwdriver/jumper/etc.

In particular, being able to reset to default configuration may be
something that should be easy to do for a untrusted operator
(i.e. CPE in residential setting), but which shouldn't change the onwership.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Michael H. Behringer" <[email-masked]>
Date: Mon, 13 Mar 2017 08:48:49 +0100

Thanks, Michael, I think we're in sync. I'll take on board your "reset 
to default configuration".

Now I wonder where this idea of the "two types of factory reset" 
actually came from? Never mind... We're all aligned, that's the key.

Michael

---

From: "Michael H. Behringer" <[email-masked]>
Date: Mon, 13 Mar 2017 11:40:36 +0100

Formulating the state machine in the reference draft, I come to the 
conclusion that we should actually *not* mention that "reset to default 
configuration" in it, because it actually has nothing to do with AN at all.

 From an AN perspective it´s important to show what happens when:
- we delete the LDevID. A factory reset does that.
- a device loses all ACP tunnels.

The configuration of the device is outside scope, I think! If a config 
change removes the last ACP tunnel (for example), then it's that removal 
that changes the state in the AN machine.

The important thing to mention (and so far missing) is IMO that *only* a 
factory re-set can remove the LDevID, otherwise we may end up with stale 
state at enrollment time. I added that point in my new section.

Please shout if you think I'm missing something.

Michael

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Mar 2017 15:26:20 -0400

Michael H. Behringer <[email-masked]> wrote:
    > change removes the last ACP tunnel (for example), then it's that
    > removal that changes the state in the AN machine.

I like this way of writing it.
As long as we have working ACP tunnels, then we can fix the configuration.

What happens when the last ACP tunnel dies?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Mar 2017 10:07:15 +1300

> What happens when the last ACP tunnel dies?

Two things that I know about should happen, IMHO:

1. The ACP "ASA" (the thing that builds and maintains the ACP) will
just revert to its initial mode where it's listening for neighbors and
periodically trying to discover neighbors.

2. A Boolean somewhere will flip to False so that users of the ACP
(including GRASP) know that they are on their own.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Mar 2017 18:42:51 -0400

> (including GRASP) know that they are on their own.

Yes.  I think that this goes into the ACP draft.  The above is the minimum...

BUT:

I think that we need additional text though... it seems to me that one might
need to do additional things specific to the device itself, but that these
things might be risky.

Specifically, I think that it the device should consider if there have been
connectivity changes provisioned (such as changing PVIDs at layer-2,
admin enabling/disabling interfaces, or firewall changes) since the last time
the ACP was working.  It should consider if it ought to revert to last known
to be working configuration, but that that is in fact the risky part.

I suspect that perhaps there is a lot of vendor-secret-sauce possibilities
here; so I don't want to be prescriptive, but rather to say that when the
last ACP connection goes down, that the device has essentially become
unmanaged, and that it needs to do something (autonomic) to return to managed
state.