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.
>> 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.
>> 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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
