On Fri, Dec 10, 2021 at 9:31 AM <[email protected]> wrote:
> Hi all, > > > > 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. > > > > (2) For the IANA section, even if ietf-voucher was already registered, the > practice is that the IANA will need to create a new entry when the new > version of the module will be published. That IANA section should ne > updated accordingly. > > > > (3) This part from the IANA module should be updated as follows: > > > > OLD: > > organization > > "IETF ANIMA Working Group"; > > contact > > "WG Web: <https://datatracker.ietf.org/wg/anima/> > > WG List: <mailto:[email protected]> > > Author: Kent Watsen > > <mailto:[email protected]> > > Author: Max Pritikin > > <mailto:[email protected]> > > Author: Michael Richardson > > <mailto:[email protected]> > > Author: Toerless Eckert > > <mailto:[email protected]>"; > > > > NEW: > > organization > > "IANA"; > > contact > > "Internet Assigned Numbers Authority > > > > Postal: ICANN > > 12025 Waterfront Drive, Suite 300 > > Los Angeles, CA 90094-2536 > > United States of America > > Tel: +1 310 301 5800 > > <mailto:[email protected]>"; > > > > (4) Make IANA’s actions easy to handle: > > > I didn't know that we have to write IANA (ICANN) postal address in the drafts. To my knowledge ICANN is in Washington, DC, but I may be wrong. Behcet > OLD: > > name: iana-voucher-assertion-type > > namespace: urn:ietf:params:xml:ns:yang:iana-voucher-assertion-type > > prefix: ianavat > > reference: RFC XXXX > > > > NEW: > > name: iana-voucher-assertion-type > > namespace: urn:ietf:params:xml:ns:yang:iana-voucher-assertion-type > > prefix: ianavat > > maintained by IANA: Y > > reference: RFC XXXX > > > > (5) > > > > OLD > > This document registers a new media type in the "Media Types" > > registry [RFC6838]. IANA has registered the following: > > > > NEW: > > This document requests IANA to update the following "Media Types" > > entry to point to the RFC number that will be assigned > > to this document: > > > > (6) > > > > OLD: > > IANA has registered the following OID in the "SMI Security for S/MIME > > CMS Content Type (1.2.840.113549.1.9.16.1)" registry: > > > > Decimal Description References > > ------- -------------------------------------- ---------- > > 40 id-ct-animaJSONVoucher RFC 8366 > > > > > > NEW: > > This document requests IANA to update this registered OID in the > > "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" > > registry to point to the RFC number to be assigned to this document: > > > > Decimal Description References > > ------- -------------------------------------- ---------- > > 40 id-ct-animaJSONVoucher RFC XXXX > > > > (7) (many occurrences) > > > > OLD: > > reference "RFC ZZZZ: Voucher Profile for Bootstrapping Protocols"; > > > > NEW: > > reference > > "RFC XXXX: A Voucher Artifact for Bootstrapping Protocols"; > > > > (8) Consider adding an appendix to list the main changes vs. 8366. > > > > Thank you. > > > > Cheers, > > Med > > > > *De :* Anima <[email protected]> *De la part de* Sheng Jiang > *Envoyé :* lundi 6 décembre 2021 07:57 > *À :* [email protected] > *Cc :* [email protected]; Toerless Eckert <[email protected]> > *Objet :* [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. > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
