Let me Cc' Benoit and Mahesh.
My short answer is No - let's not split rfc8366bis
My long answer:
If i where to paint an ANIMA equivalency, then RFC9417 is a document we never
wrote,
namely one in which we outlined in significant details the abstract procedures
of the "any" protocol that could be built to use vouchers. Aka: all the
variations
we know to be useful/possible for different use-cases/communities between
netconf
zerotouch (aka: push to pledge), BRSKI (pull from pledge), BRSKI-PRM
(mitigation by agent),
various integrations or separations between trust establishment by voucher
,from enrollment of
certificat/trust-anchors. And we have not even touched the use of voucher in
transfer
of ownership after initial sales (old to new owner without manufacturer
involved).
Aka: the text we have in rfc8366bis IMHO matches the degree of explanations in
RFC9418,
not the one of rfc9417.
When ANIMA was chartered (guess who lead that..), there was a lot of concern of
the WG would not result in implementable functional specifications. Hence the
initial ANIMA charger explicitly excluded any real architectur document, and it
was hard enough to fight at least for RFC8993. So, i am happy to see that OPSAWG
did allow for an architecture document like RFC9417 to be written and published!
I start to think it might again be a good time to write such an architecture
document,
namely for the purpose to educate the industry that solutions like in thread
and other
industrial verticals are (unnecessarily) reinventing the wheel of onboarding,
and
that we already got a broad framework that can easily be extended. But that
type of
work would require more gathering of information from those other industry
verticals
that do/did reinvent the wheel.
And of course, RFC8995 is primarily good for implementers of that specific
protocol,
but not to most easily understand the architectural concepts of using vouchers
for enrollment or other lifecycle operations - see above.
Cheers
Toerless
On Thu, Aug 15, 2024 at 03:07:49PM -0400, Michael Richardson wrote:
>
> The pattern in NETMOD and OPSAWG in publishing documents with YANG modules is
> to publish two RFCs: one with motivation and explanation, and the other with
> just the YANG module.
> cf:
> RFC 9417 Service Assurance for Intent-Based Networking Architecture
> RFC 9418 A YANG Data Model for Service Assurance
>
> should this be done for RFC8366bis?
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
