Re: [Anima] Intent per ASA or per AF?
On 21/11/2016 06:36, Michael Behringer (mbehring) wrote: >> -Original Message- >> From: Michael Richardson [mailto:mcr+i...@sandelman.ca] >> Sent: 20 November 2016 07:42 >> To: Michael Behringer (mbehring) >> Cc: anima@ietf.org >> Subject: Re: [Anima] Intent per ASA or per AF? >> >> >> Michael Behringer (mbehring) wrote: >> > One question that just came up: Should Intent be designed per ASA or >> > per AF? >> >> > My suggestion previously was to segment Intent into sections per >> > Autonomic Functions. >> >> > Example: Intent for the bootstrap function could be: - allow >> > bootstrapping new devices only during maintenance window >> >> I agree that this is a useful policy. >> >> I come back to such pseudo-time-based Intents to wonder how they work. >> We discussed this a year ago... and never, I thought, reached consensus. >> >> I think that the answer to that would tell me how Intents should be >> partitioned. > > Not sure I completely understand, and not sure that's what I wanted to say. > My point was that a policy like above could be implemented on the proxy as > well as the registrar. Maybe in some cases on both. So, segmenting per > function seems more useful than by ASA. This conversation strengthens my conviction that we should leave this as flexible as possible, because the requirements will change with experience. In other words, label each segment of Intent - and the label may well be the name of an autonomic function - but do not make rules about the labels. That way there is flexibility for the future. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Intent per ASA or per AF?
> -Original Message- > From: Michael Richardson [mailto:mcr+i...@sandelman.ca] > Sent: 20 November 2016 07:42 > To: Michael Behringer (mbehring) > Cc: anima@ietf.org > Subject: Re: [Anima] Intent per ASA or per AF? > > > Michael Behringer (mbehring) wrote: > > One question that just came up: Should Intent be designed per ASA or > > per AF? > > > My suggestion previously was to segment Intent into sections per > > Autonomic Functions. > > > Example: Intent for the bootstrap function could be: - allow > > bootstrapping new devices only during maintenance window > > I agree that this is a useful policy. > > I come back to such pseudo-time-based Intents to wonder how they work. > We discussed this a year ago... and never, I thought, reached consensus. > > I think that the answer to that would tell me how Intents should be > partitioned. Not sure I completely understand, and not sure that's what I wanted to say. My point was that a policy like above could be implemented on the proxy as well as the registrar. Maybe in some cases on both. So, segmenting per function seems more useful than by ASA. Michael ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Intent per ASA or per AF?
Michael Behringer (mbehring) wrote: > One question that just came up: Should Intent be designed per ASA or > per AF? > My suggestion previously was to segment Intent into sections per > Autonomic Functions. > Example: Intent for the bootstrap function could be: - allow > bootstrapping new devices only during maintenance window I agree that this is a useful policy. I come back to such pseudo-time-based Intents to wonder how they work. We discussed this a year ago... and never, I thought, reached consensus. I think that the answer to that would tell me how Intents should be partitioned. -- 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] red/yellow/green lights for bootstrap and ACP feedback
Max Pritikin (pritikin) 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. -- 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
