Hi, Qin: Please see my reply inline. -----Original Message----- From: Anima [mailto:[email protected]] On Behalf Of Qin Wu Sent: Monday, December 13, 2021 11:19 AM To: Michael Richardson <[email protected]>; [email protected] Subject: Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021
Hi, Michael: >-----邮件原件----- >发件人: Michael Richardson [mailto:[email protected]] >发送时间: 2021年12月13日 4:36 >收件人: Qin Wu <[email protected]>; [email protected] >主题: Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, >ends December 19th, 2021 >Qin Wu <[email protected]> wrote: > > 1. Since we still reuse rc:yang-data to model vouch-artifact, I > > believe the model structure in section 5.1 of RFC8366 should keep as > > is. > > 2. Secondly, vouch-artifact doesn’t need to be coupled with > > RESTCONF protocol message, suggest to use YANG extension statement > > “structure” defined in RFC8791 to replace yang-data. >Sorry, I'm confused here. I think that #1 says that yang-data is okay. >I think that #2 says that yang-data is not okay, and we need sx:structure >instead? [Qin Wu] :Good catch, I think sx:structure is preferable instead. The YANG data structure in section 3 of RFC8791 can be followed. structure <structure-name>: +--<node> +--<node> | +--<node> +--<node> >Are you saying that we should update to RFC8791? >Do you think that this is a bug-fix? [Qin Wu] No, have clarified in the separate message, I think both yang-data and sx:structure can be used, but sx:structure is not targeted to replace yang-data, but RESTCONFbis in the future may consider to decouple yang-data from RFC8040. >I'm asking, because we have discussed that RFC8366bis might go forward >as a > (step-two) Internet Standard, rather than cycling at Proposed Standard. > > 3. Do we expect iana-voucher-assertion-type to be changed in the > > future, e.g., add a new enum value? Does it make sense to change > > voucher-assertion typedef into identity data type. >Yes, we expect that new documents will Extend it. >I don't know what an identity data type is here.... I thought we did the right >thing, so I do not quite understand what you are proposing. [Qin Wu] I have no strong opinion whether enum is the best option, the difference between identity and enum is identity is a text name without an associated value but enum is both a name and a value enum doesn't support augment in YANG while identity does. But the advantage of using Enum is Enum saves a lot of space than identity. Here is what identity looks like: " /* Identities */ identity voucher-assertion-type { description "Base identity for voucher assertion type. The voucher assertion is used to indicate what kind of ownership is being asserted by voucher."; } identity verified { base voucher-assertion-type; description "Identity for verified voucher assertion, which indicates that the ownership has been positively verified by the MASA (e.g., through sales channel integration)."; } identity logged { base voucher-assertion-type; description "identity for logged voucher assertion. The logged voucher assertion indicates that the voucher has been issued after minimal verification of ownership or control. The issuance has been logged for detection of potential security issues (e.g., recipients of vouchers might verify for themselves that unexpected vouchers are not in the log). This is similar to unsecured trust-on-first-use principles but with the logging providing a basis for detecting unexpected events." } ...... " [Qiufang Ma] Given this is an IANA maintained YANG module, I think it's okay to define it as enumeration type. If someone wants to add a new type, a request has to be made to IANA registry, and IANA will update the YANG module and add a new "enum" statement accordingly. An enumeration data type defined here makes it controlled by a single authority. Best Regards, Qiufang Ma -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
