Subject: Re: [netconf] [Anima] Reuse of SZTP-CSR YANG definition in BRSKI-AE

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jun 2021 17:29:35 -0400

Kent Watsen <[email-masked]> wrote:
    > [future threads about SZTP should CC NETCONF, the WG that
    > published/maintains SZTP]

Yes, and not netmod?

    sf> In one use case, the pledge has no direct connection to the registrar
    sf> and a registrar-agent communicates with the pledge. In that specific
    sf> case we do not have a TLS connection between the pledge and the
    sf> registrar-agent and protect the exchanged objects by an additional
    sf> signature. This is done by embedding the necessary information into a JOSE object.

...

    sf> The question
    sf> (https://github.com/anima-wg/anima-brski-async-enroll/issues/10) now
    sf> is, if this construct is possible, as we are just using a subset
    sf> (sztp-csr:csr) of the YANG  module " ietf-sztp-bootstrap-server" from
    sf> draft-ietf-netconf-sztp-csr?

    kw> This is not possible.

I feel that the question might have been so specific that it didn't match.

My thought was to do CORECONF (possibly using CoAP over BTLE), to retrieve a
CSR from a device.  It seems to fit right into the ietf-sztp-bootstrap-server
pattern to me.

So, I'm unclear why ietf-sztp-csr:csr-support couldn't be used.
Is it because the module augments sztp, and we don't need it all?

We really just want container csr-support, csr-generation, csr, ???

Maybe we could chat about this more.
We have a regular Thursday 9:30 EST design team.

    >> The alternative would be to define an own module modeled in a similar.

    > You can do this.

I think that we can have some common mindshare here.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Jun 2021 12:50:37 +0000

Hi Michael,

>> published/maintains SZTP]

Correct.  Though questions regarding the YANG language are best post to NETMOD.

> Is it because the module augments sztp, and we don't need it all?

In part, but also because what you want is buried inside a definition and there is no mechanism to cherry-pick inner-nodes.

> I think that we can have some common mindshare here.

One option would be to move stuff into ietf-crypto-types…as that module already defines a number of grouping statements for handy structures.  That said, these structures are not context-free…they are very much entwined in a specific dialog that is rather specific to bootstrapping processes.  [FWIW,  just adding “cmc” and “cmp" typedefs to crypto-types, alongside the existing “csr” (e.g., “p10”) typedef, might be a good thing]

Another option would be to move stuff into grouping statements, in the same module, that are immediately.  In theory this would have no impact to the on-the-wire format.  However, it’s somewhat late in the process to entertain this, as the draft is in the AD queue (AD-review was just posted today) and no doubt we would dicker over how many groupings to create and whether they should be put into another draft to whitewash out the SZTP-stint.  Is it proper to reset a NETCONF publication for another WG?  Rob?

K.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jun 2021 17:02:52 -0400

> One option would be to move stuff into ietf-crypto-types…as that module
    > already defines a number of grouping statements for handy structures.
    > That said, these structures are not context-free…they are very much
    > entwined in a specific dialog that is rather specific to bootstrapping
    > processes.  [FWIW,  just adding “cmc” and “cmp" typedefs to
    > crypto-types, alongside the existing “csr” (e.g., “p10”) typedef, might
    > be a good thing]

Understood.

    > Another option would be to move stuff into grouping statements, in the
    > same module, that are immediately.  In theory this would have no impact
    > to the on-the-wire format.  However, it’s somewhat late in the process
    > to entertain this, as the draft is in the AD queue (AD-review was just
    > posted today) and no doubt we would dicker over how many groupings to
    > create and whether they should be put into another draft to whitewash
    > out the SZTP-stint.  Is it proper to reset a NETCONF publication for
    > another WG?  Rob?

If we can do this at this point, that would I think, be best for all of us.

If it's just at AD, then it hasn't gotten IESG reviews yet, and there could
be many weeks of back and forth yet to go.

The horse trading shouldn't take more than 30 minutes of real-time
discussion, maybe way less.  

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 25 Jun 2021 10:27:14 +0000

Hi Kent, Michael,

Re:
> Is it proper to reset a NETCONF publication for another WG?  Rob?

No, but if there are simple/quick changes that we can make to the NETCONF draft to make it more reusable then I think that is a good thing.

In this case, I think that this should come down to the discretion of the sZTP-CSR authors, given that BRSKI-AE also have the choice of just copying the YANG that they need.

I would be okay seeing the csr structure put into a grouping, but I would strongly prefer that they get moved out of the ietf-sztp-csr.yang module, so that the CSR groupings can be imported without requiring any import-only import dependency on ietf-sztp-csr (and possibly ietf-sztp-bootstrap-server).

Hence, my suggestion, if you were to do this, would be for a separate ietf-csr-types.yang module defined as part of the SZTP-CSR draft.

Thanks,
Rob

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Michael Richardson
Sent: 23 June 2021 22:03
To: Kent Watsen <[email-masked]>; [email-masked]; [email-masked]
Cc: Werner, Thomas <[email-masked]>; Fries, Steffen <[email-masked]>
Subject: Re: [Anima] Reuse of SZTP-CSR YANG definition in BRSKI-AE

Understood.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Jun 2021 11:57:07 -0400

> Hi Kent, Michael,

Hi!

    > In this case, I think that this should come down to the discretion of
    > the sZTP-CSR authors, given that BRSKI-AE also have the choice of just
    > copying the YANG that they need.

Yes, we can go via copy and paste method, but it seems so distastful.

    > I would be okay seeing the csr structure put into a grouping, but I
    > would strongly prefer that they get moved out of the ietf-sztp-csr.yang
    > module, so that the CSR groupings can be imported without requiring any
    > import-only import dependency on ietf-sztp-csr (and possibly
    > ietf-sztp-bootstrap-server).

    > Hence, my suggestion, if you were to do this, would be for a separate
    > ietf-csr-types.yang module defined as part of the SZTP-CSR draft.

That would be very cool.