[Anima] For the next version of GRASP...
Hi, At the moment, the only suggested updates for the next version of the GRASP draft are in this message from Toerless: https://mailarchive.ietf.org/arch/msg/anima-signaling/KyPI7tvxuAt-ehxHZ4yiEMB-qeg I didn't hear anything in the Anima sessions in Seoul that would require updates to the draft, so please do send along any other comments, however minor, as soon as possible. https://tools.ietf.org/html/draft-ietf-anima-grasp Regards Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Anima-bootstrap] weekly boostrap design team meetings
Max Pritikin (pritikin) wrote: > "time zones are hard” > I think this shifts our meetings — making them occur 1hr earlier than > they have been. > Is that intentional? Am I in error? If the meeting is anchored to UTC, then the change is because we changed our clocks two weeks ago. If you'd rather the meeting was anchored otherwise, such that it stays at 11am EST, please say so. I'm flexible regardless. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Anima-bootstrap] weekly boostrap design team meetings
"time zones are hard” I think this shifts our meetings — making them occur 1hr earlier than they have been. Is that intentional? Am I in error? - max > On Nov 17, 2016, at 8:39 PM, Michael Richardson wrote: > > > The Anima Bootstrap design team (which includes work on the ownership > voucher) will continue to meet at 15:00 UTC on Tuesdays via RTC-enabled > webex. The meeting is anchored to UTC, not EST. > > anima bootstrap design team > Tuesday, November 22, 2016 > 10:00 am Eastern Standard Time (GMT-05:00) > Recurrence: Every Tuesday, from Tuesday, > November 22, 2016, to Tuesday, March 21, 2017 > > Less information > Meeting number: 644 519 877 > Meeting password: bootstrap > Meeting link: > https://ietf.webex.com/ietf/j.php?MTID=m2045414e2e484e0ad47311ce67c1d596 > Host key: 959942 > > Audio connection: > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Show toll-free dialing restrictions > Access code: 644 519 877 > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > Anima-bootstrap mailing list > anima-bootst...@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] red/yellow/green lights for bootstrap and ACP feedback
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 wrote:
>
>
> 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 , Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
