> From: Anima <[email protected]> On Behalf Of Michael Richardson > Fries, Steffen <[email protected]> wrote: > >> My answers: > >> 1) No, I don't want to rename anything. Let BRSKI-AE establish a new > registry. > >> > >> 2) I don't want to Link Discovery, and I think it's harmful if BRSKI-AE > >> proposes this rather than it being in the base document. > > > Just to be sure I understand it right, the discovery of enrollment > > endpoints would still be part of BRSKI-AE? > > I frankly don't see the point of the discovery at all. > > 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. For the constraint case (not contained in BRSKI), the discovery of specific endpoints is more important to not overload the pledge. Based on that, I would propose to update the example in section 5.3 of BRSKI-AE to list only /.well-know instead of the currently stated /.well-know/brski.
> > >> 3) I see an alias as a waste of time. It's either a rename, or don't > >> do it. > > > Renaming would be the much clearer way forward in the light of multiple > > (different) enrollment endpoints supported at the registrar and the > > connected processing as discussed. > > 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. > > >> 4) If we want to do this, then do it in the base document. > >> Yes, with *ALL* the delay risk that Brian Carpenter mention. > > > My take from the discussion so far regarding that point was rather > > reluctance regarding changes in the base document due to the connected > > delay, but as you stated, it would be the clean way. > > Do we agree that this rename is cosmetic? > It appeals to humans, computer code does not care in any way. > If the WG can tolerate the process risk, then it shouldn't be a problem. > If we can agree by the end of the week to do this, then the changes could be > approved in less than a week, if the ADs agree that this does not require a > new > IETF LC. As this is essentially a name change and does not change the functionality of BRSKI I would assume that there is no need for an new IETF LC, which would slow down publication. With that assumption in mind, I would be in favor. 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
