>-----邮件原件----- >发件人: maqiufang (A) >发送时间: 2021年12月13日 15:10 >收件人: Qin Wu <[email protected]> >抄送: Michael Richardson <[email protected]>; [email protected] >主题: RE: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends >December 19th, 2021
>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. [Qin Wu] Thanks for clarification, I believe your comment is relate to Lada's proposal https://mailarchive.ietf.org/arch/msg/netmod/hxy7gKJ13yA0L_PYopb7usql870/ Yes, this proposal did work for me, which automate process not only for IANA registries update, but also for IANA maintained YANG module update, but I am not sure whether this proposal have been fully accepted and implemented. >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
