Subject: Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021

From: Qin Wu <[email-masked]>
Date: Sat, 11 Dec 2021 13:51:37 +0000

-----邮件原件-----
发件人: Anima [mailto:[email-masked]] 代表 Michael Richardson
发送时间: 2021年12月11日 4:46
收件人: [email-masked]
抄送: [email-masked]; Toerless Eckert <[email-masked]>; Sheng Jiang <jiangsheng=[email-masked]>; [email-masked]
主题: Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021

<[email-masked]> wrote:
    > I support adoption.

    > (1)(major) However, I think that ietf-voucher module should be reworked
    > to make use of the structure defined in RFC 8791.

That's a reasonable thing to request.
 * Do you consider it to be a bug-fix?
[Qin Wu] My understanding is no, RFC8791 didn't make any update to RFC8040, but in the future, for RESTCONF Next, RFC8040 may be updated to remove yang-data statement.

---

From: Qin Wu <[email-masked]>
Date: Mon, 13 Dec 2021 07:42:56 +0000

>-----邮件原件-----
>发件人: maqiufang (A) 
>发送时间: 2021年12月13日 15:10
>收件人: Qin Wu <[email-masked]>
>抄送: Michael Richardson <[email-masked]>; [email-masked]
>主题: 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-masked]] On Behalf Of Qin Wu
>Sent: Monday, December 13, 2021 11:19 AM
>To: Michael Richardson <[email-masked]>; [email-masked]
>Subject: Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021

>Hi, Michael:
>>-----邮件原件-----
>>发件人: Michael Richardson [mailto:[email-masked]]
>>发送时间: 2021年12月13日 4:36
>>收件人: Qin Wu <[email-masked]>; [email-masked]

>>Qin Wu <bill.wu=[email-masked]> 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-masked]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Qin Wu <[email-masked]>
Date: Mon, 13 Dec 2021 07:44:56 +0000

Good argument to stick to enum, I think it is reasonable. Thanks Med for good clarification!

-Qin
发件人: Anima [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2021年12月13日 15:39
收件人: Qin Wu <bill.wu=[email-masked]>; Sheng Jiang <jiangsheng=[email-masked]>; [email-masked]
抄送: [email-masked]; Toerless Eckert <[email-masked]>
主题: Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021

Hi Qin, all,

(3) is not an issue for an IANA-maintained module.

I do think it is better to maintain the enum rather than identities given that the document talks about future cbor mapping, for which compact encoding may be needed. If this was transformed into identities, the assertion attribute must be prefixed with “iana-voucher-assertion-type”.

Cheers,
Med

De : Anima <[email-masked]<mailto:[email-masked]>> De la part de Qin Wu
Envoyé : samedi 11 décembre 2021 14:48
À : Sheng Jiang <jiangsheng=[email-masked]<mailto:jiangsheng=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021

Hi, Chairs:
I have read the latest version of this draft and support adoption of this work. Here are a few comments:

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.

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.

-Qin
发件人: Anima [mailto:[email-masked]] 代表 Sheng Jiang
发送时间: 2021年12月6日 14:57
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; Toerless Eckert <[email-masked]<mailto:[email-masked]>>
主题: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021

Hi, all ANIMAer,

This message starts a two-week adoption call for draft-richardson-anima-rfc8366bis, which we have traced a few discussion and think the WG is interested in. The adoption call ends December 19th, 2021.

Title:   A Voucher Artifact for Bootstrapping Protocols

Name:     draft-richardson-anima-rfc8366bis-04

Authors:  K. Watsen, M. Richardson, M. Pritikin and T. Eckert

URL:      https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/

IPR:      No IPR disclosures have been submitted directly on draft-richardson-anima-voucher-delegation

This document is intended to become a standards track ANIMA WG document.

Please express your support or rejection. If you think this document should _not_ be adopted, please also explicitly indicate the reasons.

Regards,

Sheng

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.