Yes, it does. I think an explicit note that 0 is not allowed should be made however. ------------------------------
Any statements contained in this email are personal to the author and are 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 № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Wed, 12 Jul 2023 at 19:34, Paul van Brouwershaven < paul.vanbrouwersha...@entrust.com> wrote: > I have to agree that 0 is not a positive integer and reverted the prior > change: > > *> In the case that this parameter is not specified or contains the value > "0", the entry will be considered to have a lower priority than all entries > which specify any priority.* > > So, setting "0" would invalidate the parameter, causing the ACME client to > ignore the CAA record all together. > > Does this also make sense to you Q? > > ------------------------------ > *From:* Tim Hollebeek <tim.hollebeek=40digicert....@dmarc.ietf.org> > *Sent:* Wednesday, July 12, 2023 19:32 > *To:* Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com>; Q > Misell <q...@as207960.net> > *Cc:* acme@ietf.org <acme@ietf.org> > *Subject:* RE: [Acme] FW: [EXTERNAL] New Version Notification for > draft-vanbrouwershaven-acme-auto-discovery-00.txt > > > If priority is defined as a positive integer (which makes sense to me), > then zero is an error, yes. > > > > If it’s desirable to have a “no priority” value, then zero might be a > reasonable choice for such a value. But it’s hard to reason about whether > “no priority” is higher or lower than items that do have priorities, so I > think “no priority” adds additional complexity that should not be added > unnecessarily. I think it’s simpler to stick to a single, ordered list of > priority numbers, and ordinal numbers (a.k.a positive integers) are the > best way to express that. > > > > -Tim > > > > *From:* Paul van Brouwershaven <Paul.vanBrouwershaven= > 40entrust....@dmarc.ietf.org> > *Sent:* Wednesday, July 12, 2023 1:01 PM > *To:* Tim Hollebeek <tim.holleb...@digicert.com>; Q Misell <q...@as207960.net > > > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for > draft-vanbrouwershaven-acme-auto-discovery-00.txt > > > > > Anyone who argues that zero is a positive integer should be referred to > the standard math textbook of positive. Zero is a non-negative integer, > but I’m not aware of any definition of “positive” that makes it a positive > integer. > > > > Do you argue that "0" should be threatened as an error instead of equal to > no priority? > > > ------------------------------ > > *From:* Tim Hollebeek <tim.hollebeek=40digicert....@dmarc.ietf.org> > *Sent:* Wednesday, July 12, 2023 6:43:21 PM > *To:* Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com>; Q > Misell <q...@as207960.net> > *Cc:* acme@ietf.org <acme@ietf.org> > *Subject:* RE: [Acme] FW: [EXTERNAL] New Version Notification for > draft-vanbrouwershaven-acme-auto-discovery-00.txt > > > > Anyone who argues that zero is a positive integer should be referred to > the standard math textbook of positive. Zero is a non-negative integer, > but I’m not aware of any definition of “positive” that makes it a positive > integer. > > > > Also, ignoring failures in CAA records is probably not the right answer. > CAA should fail closed, not open. > > > > -Tim > > > > *From:* Acme <acme-boun...@ietf.org> *On Behalf Of *Paul van Brouwershaven > *Sent:* Wednesday, July 12, 2023 9:52 AM > *To:* Q Misell <q...@as207960.net> > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for > draft-vanbrouwershaven-acme-auto-discovery-00.txt > > > > Hi Q, > > > > Thanks, this is great and really helpful! > > Is priority=0 an error coditition, some might argue 0 is a positive > integer? > > Any suggestion? maybe we should simply start counting at 0 instead of 1 > > What about discovery=foobar? > > "foobar" is not a Boolean, the text is clear that this parameter MUST be > a Boolean, so this should invalidate the parameter. > > Should the client ignore invalid issue records and process the rest, or > fail outright? > > We should ignore the failure of a single CAA record and continue with the > next, similar to when the client encounters ACME errors. > > > > I will clarify this with the following change: > > > > *The ACME client analyzes the CAA records - > The ACME client analyzes the > valid CAA records * > > > > It looks like you implemented discovery as a pre-condition while 3.1.1 > specifies: > > > > *When this parameter is not specified the client MUST assume that > discovery is enabled.* > > > > There is however a comment in the examples that this behavior might need > to change if deemed necessary. > > > > Paul > > > > > ------------------------------ > > *From:* Q Misell <q...@as207960.net> > *Sent:* Wednesday, July 12, 2023 15:06 > *To:* Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com> > *Cc:* acme@ietf.org <acme@ietf.org> > *Subject:* Re: [Acme] FW: [EXTERNAL] New Version Notification for > draft-vanbrouwershaven-acme-auto-discovery-00.txt > > > > Hi all, > > > > I happened to be poking around the certbot codebase today and decided to > try and implement this draft. > > It turned out to be a much simpler task than I had expected, however I > felt the draft was a bit lacking in details for what the ACME client should > consider an error. > > > > For example: > > - Is priority=0 an error coditition, some might argue 0 is a positive > integer? > - What about discovery=foobar? > - Should the client ignore invalid issue records and process the rest, > or fail outright? > > My fork of certbot with the implementation is available at > https://github.com/as207960/certbot/tree/auto-discovery > <https://urldefense.com/v3/__https:/github.com/as207960/certbot/tree/auto-discovery__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g84d3UvJ3$> > . > > > > Thanks, > > Q > ------------------------------ > > Any statements contained in this email are personal to the author and are > 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 № 12417574 > <https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8-o0EXCj$>, > LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 > <https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g86EYmrmH$>. > UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. > South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered > office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, > trading as Glauca Digital, is a company registered in Estonia under № > 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo > are registered trademarks in the UK, under № UK00003718474 and № > UK00003718468, respectively. > > > > > > On Fri, 7 Jul 2023 at 14:32, Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> > wrote: > > > > - how about ratelimit? for large hosting they will hit CA's default > API ratelimit fast > > > > The HTTPAPI working group is working on standard HTTP headers for > specifying rate limits. See > > > https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/ > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g81_OWtQS$> > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8yXgZATe$> > > *Any email and files/attachments transmitted with it are intended solely > for the use of the individual or entity to whom they are addressed. If this > message has been sent to you in error, you must not copy, distribute or > disclose of the information it contains. Please notify Entrust immediately > and delete the message from your system.* >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
