The adoption period finished sone time ago with strong consensus to adopt.
Authors will want to upload their latest version.
tim
On Mon, Sep 11, 2017 at 2:52 PM, Marek Vavruša
wrote:
> I support the adoption of this document. Was there a discussion of any
> actual downsides besides "I'd like
I support the adoption of this document. Was there a discussion of any
actual downsides besides "I'd like to know if it's stale" and
monitoring?
On Mon, Sep 11, 2017 at 11:11 AM, Bob Harold wrote:
>
> On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews wrote:
>>
>>
>> Part of the problem is that we ha
On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews wrote:
>
> Part of the problem is that we have one TTL value for both freshness
> and don't use beyond.
>
> This is fixable. It is possible to specify two timer values. It
> does require adding signaling between recursive servers and
> authoritative
At Thu, 07 Sep 2017 13:42:45 -0700,
Paul Vixie wrote:
> > If we don't work on a proposal like this, I'd love to see a specific
> > counter proposal that doesn't violate the current protocol
> > specification (i.e., using a cached answer beyond its TTL) and still
> > avoids resolution failure when
tjw ietf wrote:
> August is over and my self-imposed holiday is over, so it's time to get
> busy again. We have this document marked as a candidate for adoption.
>
> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
>
> The draft is available here:
> https://datatracker.ietf
Paul Wouters wrote:
> On Fri, 8 Sep 2017, Tony Finch wrote:
>
> > It isn't possible to distribute trust anchors to BYOD
> > clients with validating stubs
>
> That's not entirely true,
> https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-02
> It supports sending INTERNAL_DNSSEC_TA trust ancho
On Fri, 8 Sep 2017, Tony Finch wrote:
It isn't possible to distribute trust anchors to BYOD
clients with validating stubs
That's not entirely true,
https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-02
It supports sending INTERNAL_DNSSEC_TA trust anchors.
Paul
___
Stephane Bortzmeyer wrote:
>
> I'm not enthousiastic. We should focus on making the DNS infrastructure
> more reliable, not on adding something to a pile of already fragile
> protocols.
I like this draft because it should help if we lose off-campus
connectivity. We've had a few incidents in recen
On Thu, Sep 07, 2017 at 02:25:14PM -0400,
Joe Abley wrote
a message of 35 lines which said:
> However, the pragmatist in me says that people are already
> implementing things like this anyway, and a standard approach is
> better for all concerned than a fragmented set of
> uncomfortably-differ
Part of the problem is that we have one TTL value for both freshness
and don't use beyond.
This is fixable. It is possible to specify two timer values. It
does require adding signaling between recursive servers and
authoritative servers, on zone transfers and update requests.
You basically add
On Thu, Sep 07, 2017 at 01:29:47PM -0700, Paul Vixie wrote:
> if the draft being considered was clear on two points, i'd support adoption.
>
> first, this feature is controversial, and there is not consensus favouring
> its
> implementation, merely its documentation.
>
> second, the initiator m
add client-intent signalling, and irrespective add server signalling
of action, and I could be there.
I'd support adoption.
On Fri, Sep 8, 2017 at 6:42 AM, Paul Vixie wrote:
> On Thursday, September 07, 2017 11:33:22 AM 神明達哉 wrote:
>> ...
>>
>> If we don't work on a proposal like this, I'd love
On Thursday, September 07, 2017 11:33:22 AM 神明達哉 wrote:
> ...
>
> If we don't work on a proposal like this, I'd love to see a specific
> counter proposal that doesn't violate the current protocol
> specification (i.e., using a cached answer beyond its TTL) and still
> avoids resolution failure whe
there will be two replies here. one to wes, one to joe.
On Thursday, September 07, 2017 10:36:50 AM Wes Hardaker wrote:
> Stephane Bortzmeyer writes:
> > I'm not enthousiastic. We should focus on making the DNS
> > infrastructure more reliable, not on adding something to a pile of
> > already fra
At Thu, 07 Sep 2017 10:36:50 -0700,
Wes Hardaker wrote:
> > I'm not enthousiastic. We should focus on making the DNS
> > infrastructure more reliable, not on adding something to a pile of
> > already fragile protocols.
>
> I don't believe we have any ideas how to make infrastructure more
> reliab
On 09/07/2017 08:25 PM, Joe Abley wrote:
> I also think if a standard specification can be obtained it ought to include
> appropriate instrumentation to allow a response to indicate whether data is
> stale or not. This seems to me just one example of a set of additional
> components we might exp
On Thu, 7 Sep 2017, Joe Abley wrote:
I hear that. I don't have a strong opinion about whether serving stale data in
general is desirable or abhorrent. However, the pragmatist in me says that
people are already implementing things like this anyway, and a standard
approach is better for all con
On 7 Sep 2017, at 11:42, Stephane Bortzmeyer wrote:
> On Tue, Sep 05, 2017 at 03:25:39PM -0400,
> tjw ietf wrote
> a message of 77 lines which said:
>
>> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
>>
>> The draft is available here:
>> https://datatracker.ietf.org
Stephane Bortzmeyer writes:
> I'm not enthousiastic. We should focus on making the DNS
> infrastructure more reliable, not on adding something to a pile of
> already fragile protocols.
I don't believe we have any ideas how to make infrastructure more
reliable in the face of DDoS attacks. Is you
Stephane Bortzmeyer wrote:
On Tue, Sep 05, 2017 at 03:25:39PM -0400,
tjw ietf wrote
a message of 77 lines which said:
This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
The draft is available here:
https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/
I'm
On Tue, Sep 05, 2017 at 03:25:39PM -0400,
tjw ietf wrote
a message of 77 lines which said:
> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/
I'm not enthousiastic. We sho
On 09/05/2017 09:25 PM, tjw ietf wrote:
> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
I do support the adoption. We plan to support some kind of
stale-serving in knot-resolver soon, so
I'm certainly willing to review and perhaps contribute some suggestions.
Still, I wo
+1
> On Sep 6, 2017, at 1:04 PM, Jared Mauch wrote:
>
> I support adoption of the document.
>
> - Jared
>
>> On Sep 5, 2017, at 3:25 PM, tjw ietf wrote:
>>
>> August is over and my self-imposed holiday is over, so it's time to get busy
>> again. We have this document marked as a candidate
I support adoption of the document.
- Jared
> On Sep 5, 2017, at 3:25 PM, tjw ietf wrote:
>
> August is over and my self-imposed holiday is over, so it's time to get busy
> again. We have this document marked as a candidate for adoption.
>
> This starts a formal Call for Adoption for draft-
August is over and my self-imposed holiday is over, so it's time to get
busy again. We have this document marked as a candidate for adoption.
This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
The draft is available here:
https://datatracker.ietf.org/doc/draft-tale-dnsop-serv
25 matches
Mail list logo
