> collect all known requirements for vouchers in RFC8366bis hoping that
> we covered all to avoid increasing complexity during augmentation of the
voucher.
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 extensions. So, the future requirements and their mechanism
can be developed independently without update BRSKI fundamental specification.
However, by saying the above, I can also accept your abovementioned model as if
this rfc8366bis is BRSKI-final.
Regards,
Sheng
------------------ Original ------------------
From: "Fries, Steffen"<[email protected]>;
Date: Thu, Feb 2, 2023 03:29 PM
To: "Sheng Jiang"<[email protected]>; "Michael
Richardson"<[email protected]>;
Cc: "anima"<[email protected]>; "Toerless Eckert"<[email protected]>;
"anima-chairs"<[email protected]>;
"draft-ietf-anima-brski-prm"<[email protected]>;
"ietf"<[email protected]>;
Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-prm-06, ends Feb.
15th, 2023
Hi Sheng,
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. That said, I see a
normative reference of BRSKI-PRM to RFC 8366bis but not necessarily vice
versa. RFC 8366bis would describe the voucher and also the voucher request with
all currently known fields and would leave the usage of these field up too the
referring RFCs.
With that, as Michael pointed out, we would get rid of the voucher specific
details in BRSKI-PRM. The technical concept of BRSKI-PRM can be reviewed
independent of this. I assumed this was the target of the WGLC.
BTW, we have another normative dependency on JWS-Voucher, which to my
understanding is also ready for WGLC.
Best regards
Steffen
From: Sheng Jiang <[email protected]>
Sent: Donnerstag, 2. Februar 2023 08:13
To: Michael Richardson <[email protected]>
Cc: anima <[email protected]>; Toerless Eckert <[email protected]>;
anima-chairs <[email protected]>; draft-ietf-anima-brski-prm
<[email protected]>; ietf <[email protected]>
Subject: Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023
> Hi, please be aware that the YANG components of this will be moved to
> rfc8366bis. They are already in the rfc8366bis-05, but I don't yet
feel > that we have *WG* Consensus to do this. In general, I don't have
preference whether this document of rfc8366bis defines YANG components. The
major differency would be rfc8366bis would depend on the brski-prm document.
That could means rfc8366bis could not be published as RFC until brshi-prm
published. I think an independent rfc8366bis could move faster. However, as I
said, I don't have personal preference. I am fine either way。 I would leave
this to authors‘’ choice. Regards, Sheng
------------------ Original ------------------
From: "Michael Richardson"<[email protected]>;
Date: Thu, Feb 2, 2023 03:34 AM
To: "Sheng Jiang"<[email protected]>;
Cc: "anima"<[email protected]>; "Toerless Eckert"<[email protected]>;
"anima-chairs"<[email protected]>;
"draft-ietf-anima-brski-prm"<[email protected]>;
"ietf"<[email protected]>;
Subject: Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023
Sheng Jiang <[email protected]> wrote:
> This message starts the two-week (*) ANIMA Working Group
Last Call to
> advance draft-ietf-anima-brski-prm-06, which specifies
enhancements to
> BRSKI (RFC8995) to facilitate bootstrapping in domains
featuring no or
> only time limited connectivity between a&nbsp;pledge
and the domain
Hi, please be aware that the YANG components of this will be moved to
rfc8366bis. They are already in the rfc8366bis-05, but I don't yet feel
that we have *WG* Consensus to do this.
Toerless has asked me to regurgitate the entire discussion, again, which I
think that I won't do.
> If you do not feel this document should advance, please
state
> your reasons why
So, as much as I'd like it to advance, I don't think it can advance until we
agree what to do with the YANG.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
