Hi Michael,

>> [future threads about SZTP should CC NETCONF, the WG that
>> published/maintains SZTP]
> 
> Yes, and not netmod?

Correct.  Though questions regarding the YANG language are best post to 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?

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


> 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.

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.






_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to