> - Section 1.2.1 doesn't address the case where a local > Registrar exists, but the Pledge is intended to use the employer's Registrar > instead. Is that in-scope?
I missed this comment in your original email. This would be a good problem to have, because it means BRSKI has become ubiquitous :-) In RFC8994 (ACP) usage, but also in constrained-BRSKI scenarios we deal the problem of which network to join. An ISP router drop-ships some 4U 400G router to a DC, and remote-hands plug a bunch of fibres in. Only most of the interfaces are to *other* ISPs (or IXP!), and if they all do BRSKI, then the device has to attempt onboarding on each interface. Ideally, concurrently, as explained in 8995 section 4.1. This is illustrated at: https://www.youtube.com/watch?v=8ZyK99Ln2sY starting at 4:45ish. (Watch at 2x. More videos at: https://brski.org/brski-impls.html ) The BRSKI-CLOUD chain of Cloud Registrars would also run concurrent with other sources. Possibly some additional text saying this should be concurrent with 8995 is needed. Hoping my co-authors have a good idea for where. If one of the Registrars are promiscuous mode (any device/manufacturer accepted), then that registrar might think it can proceed. However, the MASA, through supply chain details that are really mandatory for the cloud-registrar to function, would reject the "local" Registrar. Imagine an employee had received their (pandemic) VoIP phone at home, and it was onboarded correctly at their home, and they then go into some office. (A consultant who is onsite for a month at another company, for instance) They bring their phone with them so that they can receive company calls. When moving that phone, the phone should not be factory defaulted, so it would not go back to Pledge mode, and it would not be confused by the Registrar at the company that they are visiting. When onboarding via one or more Join Proxy(ies), where there are multiple possible registrars behind the proxy (but each proxy contains registrars all from the same domain), then we also get into larger discovery issues that draft-ietf-anima-brski-discovery tries to deal with. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
