Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Seo Suchan <[e-mail]>]

I think make priority descending order removes such headache: default is 
0 and so it has lowest priority than any other integer, make no reason 
to treat 0 exceptionally.


2023-07-13 오전 3:34에 Paul van Brouwershaven 이(가) 쓴 글:
> 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=[e-mail]>
> *Sent:* Wednesday, July 12, 2023 19:32
> *To:* Paul van Brouwershaven <[e-mail]>; Q 
> Misell <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *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=[e-mail]>
> *Sent:* Wednesday, July 12, 2023 1:01 PM
> *To:* Tim Hollebeek <[e-mail]>; Q Misell 
> <[e-mail]>
> *Cc:* [e-mail]
> *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=[e-mail]>
> *Sent:* Wednesday, July 12, 2023 6:43:21 PM
> *To:* Paul van Brouwershaven <[e-mail]>; Q 
> Misell <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *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 <[e-mail]> *On Behalf Of *Paul van Brouwershaven
> *Sent:* Wednesday, July 12, 2023 9:52 AM
> *To:* Q Misell <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]>
> *Sent:* Wednesday, July 12, 2023 15:06
> *To:* Paul van Brouwershaven <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *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=[e-mail]> 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
>     [e-mail]
>     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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme