Let me rephrase to make clear i understand.
We've got (A) BRSKI, and (B) and (C) two "independent" amendmentds
driven as independent RFCs. And neither (B) has (C) as reference,
nor vice versa, but both refer only to (A).
When a user wants to build product incorporating (A), (B), (C),
i am sure there is something we could have done wrong in (B), (C) so
you can not build an (A) amended by both (B) and (C). Worst case
(B) and (C) do conflicting amendmends by amending with the same
names. Which i guess we can safely exclude, but is that really the
only thing that can go awry ?
But lets assume we're past the "conflict" stage, and know the right
way to amend without conflict:
How much value is then in duplicating these amendmends into rfc8366bis ?
I guess we could amend (A), (B) and (C) in it if we wanted to, without
changing the semantic (and optional aspects) of what was added in
(A), (B) (C) ? And if we can do it, we should do it after (B), (C) became
(RFC, just to pull all stuff together ?
Cheers
Toerless
On Fri, Jul 29, 2022 at 10:03:05AM -0400, Michael Richardson wrote:
>
> Fries, Steffen <[email protected]> wrote:
> > Thank you for the clarification. This means we don't have to change
> > anything in either BRSKI-PRM and constraint voucher, resp. in the
> > general approach we use the voucher.
>
> Yes!
> I was worred that there were dragons in the future, but seems not.
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
