> From: Michael Richardson <[email protected]> > Fries, Steffen <[email protected]> wrote: > >> I understand the use case with CoAP, where one wants to be able to > multicast a > >> request to /.well-known/core to find out which devices support a > particular > >> service. > >> HTTP does not have the same thing, so I don't see the point of agility > in > the end > >> points if they are all in /.well-known anyway. > > > Agreed. As BRSKI-AE is intended to extend BRSKI and therefore uses > > HTTP, there is no need for a specific enhancement. The discovery using > > /.well-known will provide all available endpoints to the pledge, which > > then can evaluate the response. From an application perspective I would > > expect that the pledge may not support multiple enrollment approaches > > and simply try whatever he supports. The domain registrar would be the > > more capable component to support multiple options. > > Can you explain to me why the discovery via /.well-known/brski is useful? > This is on the *REGISTRAR*. The intention was to let the pledge or the pledge-agent know in advance what enrollment options are available at the registrar side allowing the pledge to fail fast if it does not have a matching enrollment protocol. For the original BRSKI, this is not the case, as both sides support the same feature set. In BRSKI-AE allowing alternative enrollment protocols, the registrar may support multiple different ways. To avoid make support for specific protocols mandatory on the registrar side, discovery of supported options was intended. Based on the discussion we had after the last meeting I think the discovery of /.well-known/ would be sufficient.
> In reading BRSKI-AE, I seem to be missing any place where the PUSH > mechanism is described. In a PUSH use case, what protocol would the > pledge expose to the pledge-agent and/or commissioner? This is currently left outside in terms of the protocol. The intention was to only specify the necessary (signature wrapped) data objects to be exchanged, to be open regarding the underlying transport between the pledge and the pledge-agent. This also would allow to use an arbitrary pledge-agent, but this is up for discussion. I'm currently thinking about the necessity to be able to authenticate the pledge-agent using an LDevID, if we solely rely on the objects. Authentication could also be done using HTTP authentication merely to authorize the pledge-agent to act as proxy between the pledge and the registrar. > As far as I can tell, in the PULL case, when CMP (or another mechanism) will > be used, there is still a voucher exchange first. The Registrar can express > it's > preference in the (parboiled) voucher-request from Registrar to MASA. PULL was meant to describe the behavior of the pledge to start the onboarding while PUSH was more the trigger from the pledge-agent. As the enrollment is between the pledge, the registrar, and the CA, I would not see a need to include this information in the voucher. This should be done as outlined in BRSKI. > > The MASA, if the pledge supports the desired enrollment protocol, could > include the hint. In fact, the MASA could include an entire URL with meta- > data about the protocol to use. > > This would jive very nicely with the brski-cloud mechanism!!! Hm, haven't though about this. In case of standard BRSKI I would not see a need, as it would be handled by the domain registrar, but in case of the cloud registrar, it would provide the option to point to the right domain registrar supporting the enrollment. > > > For the constraint case (not contained in BRSKI), the discovery of > > specific endpoints is more important to not overload the pledge. > > I don't understand this at all. What do you mean, overload the pledge? > Are you talking about network or code space or what? I was referring to the discovery of specific endpoints. In case of /.well-known the registrar would deliver all endpoints including their options supported, while in case of asking for a specific endpoint only delivers the specific options of that endpoint. What I meant to say was that the pledge only gets the necessary information about the endpoints he needs not all. So it would relate to the processing on the pledge. > > >> If there is value in renaming, then lets do it RIGHT NOW. > >> I DO NOT WANT to confuse the market by having an RFC come out, > followed by > >> another one 'correcting' it six months later. > >> I CAN NOT live with that situation. > > > As stated before, the value from my understanding is more clarity > > (distinct naming) regarding the provided services/endpoints. > > yes, but that's a cosmetic issue. > it appeals to humans, but it makes no technical difference. > Nevertheless, if we can do this quickly, then let's do it. > I've provided proposed text in the form of a diff, the ADs have agreed to a > process, the chairs , just need to run it. It may be cosmetic, but it would be consistent regarding the functionality provided by the specific endpoint if alternative enrollment options are used. > > I hope that your(Siemens) Thomas Werner will comment. I will give him a trigger ;-) Best regards Steffen > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
