You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initially when RFC8990...RFC8995 was written, the GRASP objectives in support of BRSKI to be used exclusively via the ACP, hence they where called AN_registrar and AN_join_proxy.
In brski discovery we should clarify whether or not these objective names are valid by default ubiquitously across any possible instances of how GRASP is built, not only ACP.
Unless we come up with good reasons not to say so, i think this is what we should write into brski discovery for clarification to make it clear that such reuse is fine. Any draft that needs different objective names for whatever reason is still free to do so.
The text was updated successfully, but these errors were encountered:
Remember that GRASP requires a secure substrate, even the RFC8994 ACP is not used. So yes, reuse of the mechanism and specific objectives is fine, but (except in DULL mode) it is never OK to use GRASP without underlying security.
(That's why I did draft-carpenter-anima-quads-grasp.)
Issues mostly as a reminder to think about it:
Initially when RFC8990...RFC8995 was written, the GRASP objectives in support of BRSKI to be used exclusively via the ACP, hence they where called AN_registrar and AN_join_proxy.
In brski discovery we should clarify whether or not these objective names are valid by default ubiquitously across any possible instances of how GRASP is built, not only ACP.
Unless we come up with good reasons not to say so, i think this is what we should write into brski discovery for clarification to make it clear that such reuse is fine. Any draft that needs different objective names for whatever reason is still free to do so.
The text was updated successfully, but these errors were encountered: