Re: [netmod] [Anima] mcr's YANG question raised during the ANIMA WG session

["Fries, Steffen" <[e-mail]>]

Hi Toerless

> -----Original Message-----
> From: Toerless Eckert <[e-mail]>
> Sent: Dienstag, 2. August 2022 02:09
> 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).
No, the current status of the voucher/voucher request amends like this for BRSKI-PRM:
RFC8366 (base voucher definition) -> (A) RFC 8995 (BRSKI definition of voucher request)  -> (B) BRSKI-PRM (includes additional fields for the registrar-agent)

> 
> 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.
At least for BRSKI-PRM we initially had reproduced what was stated in RFC 8995, but after the review comments we changed it to directly use RFC8995 defined voucher request and only amend the additional fields. So we have a clear dependency on RFC 8995, which is fine in general, as BRSKI-PRM was intended as enhancement.

> 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 did not assume that the amendments would go into RFC8366bis. The main point for the RFC8366bis changes from may understanding were reasoned by the enum used for the assertions. There was a proposal to change it. 

> 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 ?
At least BRSKI-PRM depends on the changes in RFC8366bis to be able to use the assertion "agent-proximity". Regarding the amendments I currently don't see a value in pulling it all together as they are specified in different documents. 

Best regards
Steffen



> 
> Cheers
>     Toerless
> 
> On Fri, Jul 29, 2022 at 10:03:05AM -0400, Michael Richardson wrote:
> >
> > Fries, Steffen <[e-mail]> 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 <[e-mail]>, Sandelman Software
> Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> 
> 
> 
> --
> ---
> [e-mail]