Wes Hardaker wrote:
>
> + Response: Those three codes were supplied in a previous comment
> round and they are supposed to indicate policies being applied from
> different sources. Can you check the new text of them to see if
> they are more understandable now?
The filtering / bloc
Tony Finch writes:
> Some questions about the intended meanings...
Thanks Tony,
Thanks for the comments. Responses are inline below in my tracking
notes below.
14.9 DONE Tony Finch in a sub thread to Paul
Some questions about the intended meanin
Paul Hoffman writes:
Thanks Paul,
Thanks for the comments. Responses are inline below in my tracking
notes below.
14.8 DONE Paul Hoffman previously
~
14.8.1 DONE Proposal: add the following sentence to the end of the abstract:
--
On 9/12/19 8:10 PM, Viktor Dukhovni wrote:
> SERVFAIL means, and will continue to mean, I can't help you, better luck next
> time (or elsewhere).
>
> The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not
> override RCODEs. They are not a more fine-grained RCODE one might "act o
Some questions about the intended meanings...
3.6. Extended DNS Error Code 5 - DNSSEC Indeterminate
If I remember correctly, there isn't a consistent definition of what
"indeterminate" means. Perhaps it's worth adding a reference to the
intended definition.
[ actually maybe all the codes could
> On Sep 13, 2019, at 9:38 AM, Paul Hoffman wrote:
>
>> "There are many reasons that a DNS query may fail, some of them
>> transient, some permanent; some can be resolved by querying another
>> server, some are likely best handled by stopping resolution.
>> Unfortunately, the error signals that a
On Sep 13, 2019, at 4:16 AM, Ray Bellis wrote:
> On 12/09/2019 19:10, Viktor Dukhovni wrote:
>
>> That's the crux of the matter and, in short, *no*, that's not (or should
>> not be) the motivation.
>> SERVFAIL means, and will continue to mean, I can't help you, better luck
>> next
>> time (or e
On 12/09/2019 19:10, Viktor Dukhovni wrote:
That's the crux of the matter and, in short, *no*, that's not (or should
not be) the motivation.
SERVFAIL means, and will continue to mean, I can't help you, better luck next
time (or elsewhere).
The new EDEs are *diagnostic* detail to aid in tr
> On Sep 12, 2019, at 12:42 PM, Vittorio Bertola
> wrote:
>
> But isn't the foremost motivation of this document to allow the client to
> tell between SERVFAIL due to DNSSEC validation failure and SERVFAIL due to
> resolver issues, and try another resolver in the latter case but not in the
>
> Il 12 settembre 2019 16:52 Paul Hoffman ha scritto:
>
> Proposal: add the following sentence to the end of the abstract: "Extended
> error information does not change the processing of RCODEs."
>
> Proposal: add to the end of the Introduction: Applications MUST NOT change
> the processing
On Sep 11, 2019, at 9:50 PM, Wes Hardaker wrote:
>
> 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 sec
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 l
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 code
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
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 ro
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 rough, I'll be quiet.
Sorry, I'm a bit slow tonight; can
it sounds to me that a discussion on assumptions with EDEs and RCODES would
be useful in the security considerations section as well.
and Wes, it should be "Receivers MUST be" and not "Receives MUST be" in
your last sentence.
Tim
On Tue, Sep 10, 2019 at 8:43 PM Paul Hoffman wrote:
> On Sep 10
On Sep 10, 2019, at 4:02 PM, Wes Hardaker wrote:
>
> Paul Hoffman writes:
>
>> On Sep 9, 2019, at 9:05 PM, Wes Hardaker wrote:
>>>
>>> Paul Hoffman writes:
>>>
>>> Hi Paul,
>>>
>>> Thanks for the comments and good suggestions. Responses below inside my
>>> todo list of action:
>>>
>>> 12
18 matches
Mail list logo
