From: Ben Schwartz
Date: Wednesday, February 14, 2024 at 11:34
To: Edward Lewis , Manu Bretelle
Cc: "dnsop@ietf.org"
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting
expectations in protocol definitions
> For the "testing" flag, the
oads.
--Ben
From: DNSOP on behalf of Edward Lewis
Sent: Wednesday, February 14, 2024 7:23 AM
To: Manu Bretelle
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting
expectations in protocol definitions
From: Manu Bre
From: Manu Bretelle
Date: Tuesday, February 13, 2024 at 19:03
To: Edward Lewis
Cc: "dnsop@ietf.org"
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting
expectations in protocol definitions
First - why am I resisting this proposal? I believe that fo
ng
to fallback while the flag is on? I think from an operational point of
view, this is something that can be of great help to build operational
confidence and expertise without taking the risk to break one's DNS.
Manu
>
>
> *From: *Ben Schwartz
> *Date: *Monday, February 12, 2024 at
of thought one might have had!)
From: Ben Schwartz
Date: Monday, February 12, 2024 at 16:39
To: Manu Bretelle , Peter Thomassen
Cc: Edward Lewis , "dnsop@ietf.org"
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting
expectations in protocol definitions
Manu and
us utility for
HTTPS records at present).
--Ben Schwartz
From: Manu Bretelle
Sent: Wednesday, February 7, 2024 2:19 PM
To: Peter Thomassen
Cc: Edward Lewis ; Ben Schwartz ;
dnsop@ietf.org
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting
ex
>Agreed, I don't think that the protocol should prescribe what
>to do in case of "operational error". Differentiating an
>"operational error" from an actual malicious interference is
>very likely going to be a slippery slope. That being said, I
>think it will be useful for
From: Manu Bretelle
Date: Wednesday, February 7, 2024 at 14:19
To: Peter Thomassen
Cc: Edward Lewis , Ben Schwartz ,
"dnsop@ietf.org"
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting
expectations in protocol definitions
>Agreed, I don't think that
On Thu, Feb 1, 2024 at 4:49 AM Peter Thomassen wrote:
>
>
> On 2/1/24 13:34, Edward Lewis wrote:
> > The proper response will depend on the reason - more accurately the
> presumed (lacking any out-of-band signals) reason - why the record is
> absent.
>
> Barring any other information, the proper
Automation isn't an solution in an of itself. When I recently mentioned,
during a panel discussion, that automation is essential (for scalability), an
operator on the same panel responded that automation is also a great way to
scale problems. Automation is needed but it must be automated
On 2/1/24 13:34, Edward Lewis wrote:
The proper response will depend on the reason - more accurately the presumed
(lacking any out-of-band signals) reason - why the record is absent.
Barring any other information, the proper response should IMHO not depend on
the presumed reason, but
After thinking about the response below a bit, my question would be - when a
receiver expects a record to be present, but it isn’t, what is the proper
response?
The proper response will depend on the reason - more accurately the presumed
(lacking any out-of-band signals) reason - why the
12 matches
Mail list logo
