From nobody Fri Jun 23 10:20:58 2023 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDF4C13AE3B for ; Fri, 23 Jun 2023 10:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.995 X-Spam-Level: X-Spam-Status: No, score=-6.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aaomidi.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIG1IZzCFdZ3 for ; Fri, 23 Jun 2023 10:20:52 -0700 (PDT) Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9433EC151998 for ; Fri, 23 Jun 2023 10:20:52 -0700 (PDT) Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1a9acdddb20so1402918fac.0 for ; Fri, 23 Jun 2023 10:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aaomidi.com; s=google; t=1687540851; x=1690132851; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=c0A7YZf7aoTQKBUZ9YQWISNRyFhgxodNOt6XXzHxrwU=; b=Y5/qfI695T2akZMPVrq82ENPxMvtpqd5oYc/gLU84QgVze8HF4BVPQ30Jn3mpzVM1u zxidn0ZjfHGbwG0THnHsEOvYYbVzE09xW+78fJTYnoqhW+ugi3Au8v1l62LAZzLg1EwB YarvsGtdtV2oVglXgosC5wm4ausB0DNPQXmxEgXiY5YGJEepOJZg0dIw3l9kFmN7YKXs 6IdyG/XVa/5vdOS3WvFNmT1ghEwRVafOFZ+DItHflWzYvHJkUcLIbqa62HkJrQrLjaLj nKpPUdbjXIZuTh7lAE09WS14mteVS1NS9P3kdlwAHEar0cA1onpR7AzdQ8uvViSscZUH b73A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687540851; x=1690132851; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c0A7YZf7aoTQKBUZ9YQWISNRyFhgxodNOt6XXzHxrwU=; b=KJymqv1dZEXxcsXM71MDBxnblj+SFKuLz5RTyk3+MVAj88GzyNunbzyWyKOpbnmudM n14+c3JltoyvKgu4lpoVfQ3W+hGWVSGB2OTfw1+Lj70MqPeU6X5bxiYabTTFCIseyKh/ iZwb8FJqhO8uFrqu528R6AfaI/PJnrh5izCOMRZkatVkD4SdYtNRgybUxPUCmbRhPgvt lbenKEm38Agzsx/QyeD/3v3SzaopuTsdN4mrCHYdpMctSaLqvHRawoY1QeaktC58AdIc ajHknFIHAe9bJtgLsLNYVWri9xRtLWy9UsSVYQoPXRln6OhEy7rZIOuvZUjQKObW8ph6 HFuw== X-Gm-Message-State: AC+VfDy0Nqsfh3QKXt3vWy4R9kRNn4sVC3ucrD08NsAIJ9xQzwohJEgP tOwLE/UzxkX7nGut+8RSAARHjlycxC4vElomns7HOQ== X-Google-Smtp-Source: ACHHUZ76b2r2BRlBVxoNe8X2AYSHyaxnS1PupLhgvDBZgg5j8FDY4/Gmxlam0BVI9K1Rs5uNAJpw21m54UWoG4xCfh0= X-Received: by 2002:a05:6870:7f12:b0:1a9:e938:e1c3 with SMTP id xa18-20020a0568707f1200b001a9e938e1c3mr15488159oab.23.1687540851130; Fri, 23 Jun 2023 10:20:51 -0700 (PDT) MIME-Version: 1.0 References: <22209596-7C4D-42F4-9415-98F106047C33@gmail.com> In-Reply-To: From: Amir Omidi Date: Fri, 23 Jun 2023 13:20:40 -0400 Message-ID: To: Deb Cooley Cc: "acme@ietf.org" , Amir Omidi Content-Type: multipart/alternative; boundary="000000000000f9d77905fecf3817" Archived-At: Subject: Re: [Acme] DNS-ACCOUNT-01 Updates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2023 17:20:56 -0000 --000000000000f9d77905fecf3817 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable After some deliberation on this, I think we're erring on the side of DNS-ACCOUNT-01 rather than DNS-02. Speaking to a few people privately, there is a concern that DNS-02 implies a deprecation of DNS-01 which is not the intention of this draft. This unintentional implication may be detrimental to the adoption of ACME. We're also planning on renaming the draft to draft-ietf-acme-dns-account-challenge to reduce the confusion with the two number suffixes. On Mon, May 22, 2023 at 7:33=E2=80=AFAM Deb Cooley w= rote: > What is confusing is having a numerical value as part of the draft title. > Currently: draft-ietf-acme-dns-account-01-01 which is only going to be > worse as the draft moves through version numbers. My suggestion would be > to name it without the use of a numerical value. This gets rid of both > problems. The only question is what to actually call it. > > Deb Cooley (no hats) > decoole@radium.ncsc.mil > > > > On Fri, May 19, 2023 at 8:38=E2=80=AFAM Sean Dilda wrote: > >> I don't spend a lot of time on the Let's Encrypt forums, but I do >> maintain an internal ACME server and work with the IT staff that manage >> certs/acme client installs. Most of my users are only vaguely aware th= at >> their ACME client creates an account as part of the process. Given that= , I >> suspect they would find the name 'DNS-ACCOUNT-01' confusing as it wouldn= 't >> be clear to them which account is being referred to. They would likely >> assume it would be the account on their DNS provider. I think 'DNS-02= ' >> as a newer version of the DNS challenge type would be less confusing. >> ------------------------------ >> *From:* Acme on behalf of Amir Omidi > 40google.com@dmarc.ietf.org> >> *Sent:* Thursday, May 18, 2023 5:03 PM >> *To:* Seo Suchan >> *Cc:* acme@ietf.org >> *Subject:* Re: [Acme] DNS-ACCOUNT-01 Updates >> >> I think what decision happens here will probably end up setting the >> precedent on either these digits are "version numbers" of the "base >> challenge types" (Not sure what to call them), and they act as a >> replacement of them. Or that they are another flavor of the >> technologies/protocols used in those challenges. I do not have strong >> opinions here either way. >> >> Another factor to consider is how would support/Q&A forums feel about th= e >> name choice of DNS-ACCOUNT-01 vs DNS-02. For example, if there is anyone >> here who's keeping an eye on the Let's Encrypt's community forum do you >> think DNS-02 would make things easier or harder for users adopting ACME >> based certificate issuance and the folks helping them out? If harder, do >> you think DNS-ACCOUNT-01 would be a better option here? >> >> On Sat, May 13, 2023 at 5:24=E2=80=AFAM Seo Suchan w= rote: >> >> I kinda think TLS-SNI-02 was made as version 2 of TLS-SNI-01, but it >> doesn't matter as they are no longer a thing >> 2023-05-13 =EC=98=A4=EC=A0=84 3:43=EC=97=90 Q Misell =EC=9D=B4(=EA=B0=80= ) =EC=93=B4 =EA=B8=80: >> >> >> I'm also in favour of calling it DNS-02. I highly doubt there will be >> many (if any) versions of challenges beyond version 1. It makes more sen= se >> to me to read DNS-02 and DNS challenge type 2, not a upgraded edition of >> version 1. >> ------------------------------ >> >> Any statements contained in this email are personal to the author and ar= e >> not necessarily the statements of the company unless specifically stated= . >> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, >> Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company >> registered in Wales under =E2=84=96 12417574 >> . >> ICO register =E2=84=96: ZA782876 >> . >> UK VAT =E2=84=96: GB378323867. EU VAT =E2=84=96: EU372013983. Turkish VA= T =E2=84=96: 0861333524. >> South Korean VAT =E2=84=96: 522-80-03080. Glauca Digital and the Glauca = logo are >> registered trademarks in the UK, under =E2=84=96 UK00003718474 and =E2= =84=96 UK00003718468, >> respectively. >> >> >> On Fri, 12 May 2023 at 17:58, Aaron Gable > 40letsencrypt.org@dmarc.ietf.org> wrote: >> >> For what it's worth, I'm in favor of calling it DNS-02. Despite your >> totally correct descriptions of the disadvantages of this new method, I >> *do* still view it as a generally-improved version of DNS-01. It's >> obviously backwards-incompatible, hence the new major version number, bu= t >> it is generally an improvement that creates more flexibility for clients= at >> little cost. I also find the name "DNS-ACCOUNT-01" to be slightly >> unfortunate, as no "dns accounts" are involved -- it makes sense once yo= u >> understand the method, but the name gives little to no hint to how the >> method works on its own. >> >> Aaron >> >> On Thu, May 11, 2023 at 4:52=E2=80=AFPM Antonios Chariton >> wrote: >> >> Hello everyone, >> >> I=E2=80=99m sending this e-mail to the list to update you all on DNS-ACC= OUNT-01 >> and the news we have since the presentation in IETF 116. >> >> You can all help by reviewing the text[0], these updates, and sharing >> your opinion in this thread here! >> >> The CA/B Forum 2023-05-04 meeting discussed DNS-ACCOUNT-01 and three >> things came out of it, as it is evident in the minutes[1]: >> >> 1) This method is compatible with the CA/B Forum Baseline Requirements >> that are binding for all WebPKI CAs, specifically section 3.2.2.4.7 for >> agreed-upon change to a DNS record. This means that CAs can start using >> this standard immediately, and there are no other dependencies. The desi= gn >> seemed to be good in its current version. Obviously, quick changes to th= eir >> CP/CPS may be required, but this is not blocking and unilateral. >> >> 2) There is a documented need for various usecases where this challenge >> would help, from several stakeholders, and evidence that it could be >> beneficial to the ecosystem and its development. It allows ACME to be us= ed >> in even more situations where more traditional and non-automatable metho= ds >> had to be relied upon. >> >> 3) There was a suggestion to rename this challenge to DNS-02. This is >> something that we had rejected back when we created this challenge, howe= ver >> it has been suggested several times, so we are happy to reconsider this.= It >> may be the right choice. >> >> There=E2=80=99s no published precedence of what -02 means right now, so = it=E2=80=99s >> unclear whether it is a second option, or a next generation / improved >> challenge. We never planned to replace DNS-01 with our challenge, we alw= ays >> intended to add more options, and cover more use cases. Here are some >> technical =E2=80=9Cdisadvantages=E2=80=9D of this work vs DNS-01: >> >> 1) ACME Clients need to calculate the correct label. Although we provide >> the algorithm, a bash script, and test vectors, anecdotal data from ISRG >> suggest that some clients still mess things up (implementing RFC 8555), = so >> this is another value where this may happen. An easy solution here would= be >> to share the expected label with the client, but we decided against this= to >> protect against cross-protocol attacks, and also to protect the client >> against an ACME server giving it arbitrary DNS records to change. If >> clients calculate this independently, they don=E2=80=99t need to trust t= he server. >> >> 2) The label is longer, so some very very long domain names may no longe= r >> work. Since this is 17 characters longer than DNS-01=E2=80=99s label, an= ything >> approaching the various limits (of DNS, etc.) may break. For example, if= in >> DNS-01 you end up with a 236-253 character domain name to check for the = TXT >> record, then DNS-ACCOUNT-01 will go over the limit and won=E2=80=99t wor= k. We don=E2=80=99t >> consider this to be a major problem. We=E2=80=99re also not aware of man= y domain >> names in the 236-253 character range. >> >> 3) If an ACME client for whatever reason loses access to the ACME >> account, this =E2=80=9Cset and forget=E2=80=9D DNS label now has to chan= ge. Things would >> break here with other standards too (if you need an EAB token, you can= =E2=80=99t >> create a new account anyways, if you limit the ACME account via CAA >> records, you can=E2=80=99t issue, etc.) but DNS-ACCOUNT-01 would just ad= d to the >> things that would have to be taken into account. We don=E2=80=99t curren= tly >> consider this a huge issue, but if you think it could be, let us know. >> >> As you can see, these 3 tradeoffs above had to be made, to ensure we can >> cover more use cases. We think these are good tradeoffs for an additiona= l >> ACME challenge, but perhaps they are not for an =E2=80=9Cupgraded=E2=80= =9D one. >> >> What do you think about the naming? Do you perceive =E2=80=9CDNS-02=E2= =80=9D as an >> improved version, or as a second option? We are happy to rename this to >> DNS-02 and we have no plans of breaking any ACME server or client alread= y >> using DNS-01 :) >> >> Thanks for reading through this, and I am happy to hear your thoughts an= d >> get reviews on the draft, so we can move further with this work. >> >> Antonios Chariton >> Independent Contributor ;) >> >> - - - >> Links: >> >> [0] : >> https://archive.cabforum.org/pipermail/validation/2023-May/001892.html >> >> [1] : https://daknob.github.io/draft-todo-chariton-dns-account-01/ >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >> >> _______________________________________________ >> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme= >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --000000000000f9d77905fecf3817 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After some deliberation on this, I think we're erring = on the side of DNS-ACCOUNT-01 rather than DNS-02. Speaking to a few people = privately, there is a concern that DNS-02 implies a deprecation of DNS-01 w= hich is not the intention of this draft. This unintentional implication may= be detrimental to the adoption of ACME.

We&#= 39;re also planning on renaming the draft to draft-ietf-acme-dns-account-ch= allenge to reduce the confusion with the two number suffixes.

On M= on, May 22, 2023 at 7:33=E2=80=AFAM Deb Cooley <debcooley1@gmail.com> wrote:
What is confusing= is having a numerical value as part of the draft title.=C2=A0=20 Currently:=C2=A0 draft-ietf-acme-dns-account-01-01 which is only going to b= e worse as the draft moves through version numbers.=C2=A0 My suggestion wou= ld be to name it without the use of a numerical value.=C2=A0 This gets rid = of both problems.=C2=A0 The only question is what to actually call it.=C2= =A0

Deb Cooley (no hats)



= On Fri, May 19, 2023 at 8:38=E2=80=AFAM Sean Dilda <sean@duke.edu> wrote:
I don't spend a lot of time on the Let's Encrypt forums, but I do m= aintain an internal ACME server and work with the IT staff that manage cert= s/acme client installs.=C2=A0=C2=A0 Most of my users are only vaguely aware= that their ACME client creates an account as part of the process.=C2=A0 Given that, I suspect they would find the name '= DNS-ACCOUNT-01' confusing as it wouldn't be clear to them which acc= ount is being referred to.=C2=A0 They would likely assume it would be the a= ccount on their DNS provider.=C2=A0=C2=A0=C2=A0 I think 'DNS-02' as= a newer version of the DNS challenge type would be less confusing.
From: Acme <acme-bounces@ietf.org> on behalf of Amir Omidi <aa= omidi=3D40= google.com@dmarc.ietf.org>
Sent: Thursday, May 18, 2023 5:03 PM
To: Seo Suchan <tjtncks@gmail.com>
Cc: acme@ietf.org= <acme@ietf.org>
Subject: Re: [Acme] DNS-ACCOUNT-01 Updates
=C2=A0
I think what decision happens here will probably end up se= tting the precedent=C2=A0on either these digits are "version numbers&q= uot; of the "base challenge types" (Not sure what to call them), = and they act as a replacement of them. Or that they are another flavor of the technologies/protocols used in those challenges. I do not ha= ve strong opinions here either way.

Another factor to consider is how would support/Q&A forums feel ab= out the name choice of DNS-ACCOUNT-01 vs DNS-02. For example, if there is a= nyone here who's keeping an eye on the Let's Encrypt's communit= y forum do you think DNS-02 would make things easier or harder for users adopting ACME based certificate issuance and the folks= helping them out? If harder, do you think DNS-ACCOUNT-01 would be a better= option here?

I kinda think TLS-SNI-02 was made as version 2 of TLS-SNI-01, but it doe= sn't matter as they are no longer a thing

2023-05-13 =EC=98=A4=EC=A0=84 3:43=EC=97=90 Q Misell =EC=9D=B4(=EA=B0= =80) =EC=93=B4 =EA=B8=80:

I'm also in favour of calling it DNS-02. I highly doubt=C2=A0there= will be many (if any) versions of challenges beyond version 1. It makes mo= re sense to me to read DNS-02 and DNS challenge=C2=A0type 2, not a upgraded= edition of version 1.

Any statements contained= in this email are personal to the author and are not necessarily the state= ments of the company unless specifically stated. AS207960 Cyfyngedig, havin= g a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a compan= y registered in Wales under =E2=84=96 12417574. ICO register =E2=84=96: ZA782876. UK VAT =E2=84=96: GB378323867. EU VAT =E2=84=96: EU372013983.= Turkish VAT =E2=84=96: 0861333524. South Korean VAT =E2=84=96: 522-80-0308= 0. Glauca Digital and the Glauca logo are registered trademarks in the UK, = under =E2=84=96 UK00003718474 and =E2=84=96 UK00003718468, respectively.



On Fri, 12 May 2023 at 17:58, Aaron Gable <aaron=3D40letsenc= rypt.org@dmarc.ietf.org> wrote:
For what it's worth, I'm in favor of calling it DN= S-02. Despite your totally correct descriptions of the disadvantages of thi= s new method, I *do* still view it as a generally-improved version of DNS-0= 1. It's obviously backwards-incompatible, hence the new major version number, but it is generally an improvement tha= t creates more flexibility for clients at little cost. I also find the name= "DNS-ACCOUNT-01" to be slightly unfortunate, as no "dns acc= ounts" are involved -- it makes sense once you understand the method, but the name gives little to no hint to how the met= hod works on its own.

Aaron

On Thu, May 11, 2023 at 4:52=E2=80=AFPM Antonios Chariton = <daknob.mac@gm= ail.com> wrote:
Hello everyone,

I=E2=80=99m sending this e-mail to the list to update you all on DNS-A= CCOUNT-01 and the news we have since the presentation in IETF 116.

You can all help by reviewing the text[0], these updates, and sharing = your opinion in this thread here!

The CA/B Forum 2023-05-04 meeting discussed DNS-ACCOUNT-01 and three t= hings came out of it, as it is evident in the minutes[1]:

1) This method is compatible with the CA/B Forum Baseline Requirements= that are binding for all WebPKI CAs, specifically section 3.2.2.4.7 for ag= reed-upon change to a DNS record. This means that CAs can start using this = standard immediately, and there are no other dependencies. The design seemed to be good in its current ver= sion. Obviously, quick changes to their CP/CPS may be required, but this is= not blocking and unilateral.

2) There is a documented need for various usecases where this challeng= e would help, from several stakeholders, and evidence that it could be bene= ficial to the ecosystem and its development. It allows ACME to be used in e= ven more situations where more traditional and non-automatable methods had to be relied upon.

3) There was a suggestion to rename this challenge to DNS-02. This is = something that we had rejected back when we created this challenge, however= it has been suggested several times, so we are happy to reconsider this. I= t may be the right choice.

There=E2=80=99s no published precedence of what -02 means right now, s= o it=E2=80=99s unclear whether it is a second option, or a next generation = / improved challenge. We never planned to replace DNS-01 with our challenge= , we always intended to add more options, and cover more use cases. Here are some technical =E2=80=9Cdisadvantages=E2=80=9D of= this work vs DNS-01:

1) ACME Clients need to calculate the correct label. Although we provi= de the algorithm, a bash script, and test vectors, anecdotal data from ISRG= suggest that some clients still mess things up (implementing RFC 8555), so= this is another value where this may happen. An easy solution here would be to share the expected label wit= h the client, but we decided against this to protect against cross-protocol= attacks, and also to protect the client against an ACME server giving it a= rbitrary DNS records to change. If clients calculate this independently, they don=E2=80=99t need to trust = the server.

2) The label is longer, so some very very long domain names may no lon= ger work. Since this is 17 characters longer than DNS-01=E2=80=99s label, a= nything approaching the various limits (of DNS, etc.) may break. For exampl= e, if in DNS-01 you end up with a 236-253 character domain name to check for the TXT record, then DNS-ACCOUNT-01 wil= l go over the limit and won=E2=80=99t work. We don=E2=80=99t consider this = to be a major problem. We=E2=80=99re also not aware of many domain names in= the 236-253 character range.

3) If an ACME client for whatever reason loses access to the ACME acco= unt, this =E2=80=9Cset and forget=E2=80=9D DNS label now has to change. Thi= ngs would break here with other standards too (if you need an EAB token, yo= u can=E2=80=99t create a new account anyways, if you limit the ACME account via CAA records, you can=E2=80=99t issue, etc.) but DNS-A= CCOUNT-01 would just add to the things that would have to be taken into acc= ount. We don=E2=80=99t currently consider this a huge issue, but if you thi= nk it could be, let us know.

As you can see, these 3 tradeoffs above had to be made, to ensure we c= an cover more use cases. We think these are good tradeoffs for an additiona= l ACME challenge, but perhaps they are not for an =E2=80=9Cupgraded=E2=80= =9D one.

What do you think about the naming? Do you perceive =E2=80=9CDNS-02=E2= =80=9D as an improved version, or as a second option? We are happy to renam= e this to DNS-02 and we have no plans of breaking any ACME server or client= already using DNS-01 :)

Thanks for reading through this, and I am happy to hear your thoughts = and get reviews on the draft, so we can move further with this work.

Antonios Chariton
Independent Contributor ;)

- - -
Links:

_______________________________________________
Acme mailing list
Acme@ietf.org
= https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
= https://www.ietf.org/mailman/listinfo/acme

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.or=
g/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
= https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
--000000000000f9d77905fecf3817--