Fries, Steffen wrote:
> looks fine from a BRSKI-PRM perspective. The parameters defined are
> contained. While BRSKI-PRM does not specify further values, I was
> thinking if equivalent values for the constraint case for -
> agent-provided-proximity-registrar-cert: for constraint
Sheng Jiang wrote:
> I do not prefer the "all-covered" model. As you stated, all has to be
> "known" for now. What if another unknown requirement appeared？ Another
> bis, BRSKI v3? I think it is better that rfc8366bis covers an
> extensible generic framework and rules for future
(Sheng's new email puts html in both the text/html and the text/plain parts)
> "SJ" == MichaelRichardson writes:
SJ> In general, I don't have preference whether this document of
SJ> rfc8366bis defines YANG components. The major differency would be
SJ> rfc8366bis would depend on
Fries, Steffen wrote:
> Just to chime in here, my understanding was that we collect all known
> requirements for vouchers in RFC8366bis hoping that we covered all to
> avoid increasing complexity during augmentation of the voucher.
It's not about complexity.
It's about it actually
