Subject: [Anima] red/yellow/green lights for bootstrap and ACP feedback

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Nov 2016 10:19:27 +0900

We discussed today in the meeting that the bootstrap (and overall
anima-reference-model state machine) should indicate in it's failure
transitions whether the failure is permanent, "red light", and
whether it is a "yellow light" (try again).

We may also need an "orange light" which means, "failed, but requires NMS intervention"

We didn't have time to get a sense from the room whether or not this kind of
feedback (which may ideally, be real physical feedback to the installer) is
valuable.  Of course, devices with bigger displays might want to provide more
details about the process...
  {I recall the three-digit display on the RS/6000, and the mystery that
  ensued when I had a code come up that IBM support couldn't explain....}

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 18 Nov 2016 16:00:19 +0000

The current text around error cases includes:

Section 3.1.1. Discovery
Supports a backoff mechanisms but on review I’m thinking the language about final failure to be vague:
   "Once all discovered services are attempted the device SHOULD return
   to Multicast DNS.  It should periodically retry the vendor specific
   mechanisms.  The Pledge may prioritize selection order as appropriate
   for the anticipated environment."

Section 5.1 Request Voucher from the Registrar
  "As detailed in Section 3.1.1 if no suitable Registrar is found the Pledge restarts
   the state machine and tries again.  So a Registrar that is unable to
   complete the transaction the first time will have future chances.” 

Section 5.4 Voucher Status Telemetry
This is currently worded as feedback directly to the Registrar (through the proxy of course) of failure. 

Section 5.7.4.  Enrollment Status Telemetry
This adds an enrollment status telemetry option as EST feedback has indicated this will be important for headless devices. 

Improvements could include:

A flood telemetry status indicator in addition to direct feedback to the Registrar. This would enable any local equipment to better report the Pledge’s state. I suppose this SHOULD be signed but may be unsigned to avoid extra processing overhead on the Pledge.  This would leak the Pledge’s identity information so there are privacy/security concerns but it does provide feedback. 

Normative text indicating physical indicators such as a blinking LED associated with each discovery state could be RECOMMENDED for capable devices. Obviously some devices simply won’t have such things so this can’t be required. Doing this would help clarify the discovery states. Although keep in mind the existing s3.1.1.1 recommendation that "Methods SHOULD be run in parallel to avoid head of queue problems”; meaning that the states indicated might be a generic “discovery”. 

- max

> On Nov 17, 2016, at 6:19 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Nov 2016 15:26:36 +0900

Max Pritikin (pritikin) <[email-masked]> wrote:
    > Section 3.1.1. Discovery Supports a backoff mechanisms but on review
    > I’m thinking the language about final failure to be vague: "Once all
    > discovered services are attempted the device SHOULD return to Multicast
    > DNS.  It should periodically retry the vendor specific mechanisms.  The
    > Pledge may prioritize selection order as appropriate for the
    > anticipated environment."

Michael B and I had some long conversation about how manufacturers configure
new nodes.  We are pretty sure that they will require either audit tokens,
or ownership vouchers, never both.  As part of that definition, the
manufacturer would also decide what other vendor specific mechanisms will
exist.

So to emphasize your point, our role isn't to say what those mechanisms are,
(with the exception of mDNS, which I'd like to put into an appendix), but
rather when they get used in the state machine.

    > Section 5.1 Request Voucher from the Registrar "As detailed in Section
    > 3.1.1 if no suitable Registrar is found the Pledge restarts the state
    > machine and tries again.  So a Registrar that is unable to complete the
    > transaction the first time will have future chances.”

    > A flood telemetry status indicator in addition to direct feedback to
    > the Registrar. This would enable any local equipment to better report
    > the Pledge’s state. I suppose this SHOULD be signed but may be unsigned
    > to avoid extra processing overhead on the Pledge.  This would leak the
    > Pledge’s identity information so there are privacy/security concerns
    > but it does provide feedback.

I think that this can be decoupled from our work, and we could define this
later?  I think it's pretty important, but I want to get it right.

    > Normative text indicating physical indicators such as a blinking LED
    > associated with each discovery state could be RECOMMENDED for capable
    > devices. Obviously some devices simply won’t have such things so this
    > can’t be required. Doing this would help clarify the discovery
    > states. Although keep in mind the existing s3.1.1.1 recommendation that
    > "Methods SHOULD be run in parallel to avoid head of queue problems”;
    > meaning that the states indicated might be a generic “discovery”.

Glad you agree about the difficulties here, yet the opportunity is clear.