Hi Sheng, “All known for now” would be the approach to my understanding. As I understood Michael’s current experiences, there is no easy way to provide extensibility to the voucher, which lead to the proposal to include the current state of known requirements into RFC 8366bis. Note that this document describes the voucher and the voucher request. That said, it does not necessarily require an update to one of the current BRSKI documents, assumed, that the syntax is backward compatible if new changes/additions are made to the voucher or voucher request.
Best regards Steffen From: Sheng Jiang <[email protected]> Sent: Donnerstag, 2. Februar 2023 10:41 To: Fries, Steffen (T CST) <[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 > 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]<mailto:[email protected]>>; Date: Thu, Feb 2, 2023 03:29 PM To: "Sheng Jiang"<[email protected]<mailto:[email protected]>>; "Michael Richardson"<[email protected]<mailto:[email protected]>>; Cc: "anima"<[email protected]<mailto:[email protected]>>; "Toerless Eckert"<[email protected]<mailto:[email protected]>>; "anima-chairs"<[email protected]<mailto:[email protected]>>; "draft-ietf-anima-brski-prm"<[email protected]<mailto:[email protected]>>; "ietf"<[email protected]<mailto:[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]<mailto:[email protected]>> Sent: Donnerstag, 2. Februar 2023 08:13 To: Michael Richardson <[email protected]<mailto:[email protected]>> Cc: anima <[email protected]<mailto:[email protected]>>; Toerless Eckert <[email protected]<mailto:[email protected]>>; anima-chairs <[email protected]<mailto:[email protected]>>; draft-ietf-anima-brski-prm <[email protected]<mailto:[email protected]>>; ietf <[email protected]<mailto:[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]<mailto:[email protected]>>; Date: Thu, Feb 2, 2023 03:34 AM To: "Sheng Jiang"<[email protected]<mailto:[email protected]>>; Cc: "anima"<[email protected]<mailto:[email protected]>>; "Toerless Eckert"<[email protected]<mailto:[email protected]>>; "anima-chairs"<[email protected]<mailto:[email protected]>>; "draft-ietf-anima-brski-prm"<[email protected]<mailto:[email protected]>>; "ietf"<[email protected]<mailto:[email protected]>>; Subject: Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023 Sheng Jiang <[email protected]<mailto:[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 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]<mailto:[email protected]>>, Sandelman Software Works -= IPv6 IoT consulting =-
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
