On Wed, Sep 11, 2019 at 08:22:37PM +0100, Tony Finch wrote:
> 3.2.1. Format
>
> All RRs have the same top level format shown below:
>
> [ snip ]
>
> TTL a 32 bit signed integer that specifies the time interval
> that the resource record may be cached before the
Tim Wicinski writes:
> it sounds to me that a discussion on assumptions with EDEs and RCODES
> would be useful in the security considerations section as well.
I'll look at wording along those lines.
Note, however, that EDE codes are specifically meant as supplemental
information and shouldn't
Viktor Dukhovni wrote:
>
> I am a bit puzzled by the lack of text that motivates treating TTLs
> with the high bit set as positive? Why is this desirable, and why
> in this draft? What is the connection between TTLs with the high
> bit set and Serve Stale? If some resolver inadvertently
Loganaden Velvindron writes:
> On Wed, Sep 11, 2019 at 7:42 AM Wes Hardaker wrote:
> >
> > Loganaden Velvindron writes:
> >
> > Hi Loganaden,
> >
> > Thanks for the comments about the EDE draft. I've marked up your
> > comments with responses and actions below. Let us know if you have any
>
> On Sep 11, 2019, at 12:13 PM, The IESG wrote:
>
> 'Serving Stale Data to Improve DNS Resiliency'
>
It looks to me like the list of resolvers that implement "Serve Stale"
in Section 3 contains a typo. Should "Know" be "Knot"?
A number of
On Sep 11, 2019, at 4:02 PM, Wes Hardaker wrote:
>
> Tim Wicinski writes:
>
>> it sounds to me that a discussion on assumptions with EDEs and RCODES
>> would be useful in the security considerations section as well.
>
> I'll look at wording along those lines.
>
> Note, however, that EDE
Paul Hoffman writes:
> On Sep 11, 2019, at 4:02 PM, Wes Hardaker wrote:
> >
> > Tim Wicinski writes:
> >
> >> it sounds to me that a discussion on assumptions with EDEs and RCODES
> >> would be useful in the security considerations section as well.
> >
> > I'll look at wording along those
On Tue, Sep 10, 2019 at 08:45:36PM -0700, internet-dra...@ietf.org wrote:
> Filename: draft-ietf-dnsop-extended-error-09.txt
Introduction 3rd paragraph (missing verb, extra period):
[...] These extended DNS error codes [are?] described in this
document and can be
On Wed, Sep 11, 2019 at 7:42 AM Wes Hardaker wrote:
>
> Loganaden Velvindron writes:
>
> Hi Loganaden,
>
> Thanks for the comments about the EDE draft. I've marked up your
> comments with responses and actions below. Let us know if you have any
> questions.
Hi Wes,
One small note: This reply
On Sep 10, 2019, at 10:21 PM, Evan Hunt wrote:
>
> On Wed, Sep 11, 2019 at 12:42:53AM +, Paul Hoffman wrote:
>> Thanks. However, I still think this opens a lot of security holes if
>> developers try to be "smart" by assuming that some EDEs only make sense
>> with some RCODEs. If I'm in the
I am handling this document as responsible AD, as Warren is a
co-author and so must recuse himself. I’m not sure how I missed the
publication request, but miss it I did, and thanks to Warren for
pinging me.
Thanks for a very well-written and clear document. I have only some
minor editorial
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Serving Stale Data to Improve
DNS Resiliency'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action.
12 matches
Mail list logo
