Hi,
Strong objections to this answer, or can we call it done?
ISTM that the avoidance of ambiguity for implementers is the key thing here, so
I’m especially interested in hearing from anyone who’s not sure how to code
this as written.
Thanks all for a good discussion, and the suggestion that
On 27 September 2016 at 12:28, White, Andrew
wrote:
> Hi Shumon,
>
>
>
> True. When a resolver gets an NXDOMAIN for, say x.example.com, would it
> better to say the resolver SHOULD drop from cache all descendents of
> x.example.com, or MAY?
>
>
>
> It may be computationally expensive to search ca
Jim, I asked you this privately, but your mail server bounced my mail for
no obvious reason with:
550 5.7.1 : Client host rejected:
No thanks.
So, what do you think "the root cause" is?
On Tue, Sep 27, 2016 at 2:38 PM, Jim Reid wrote:
>
> > On 27 Sep 2016, at 18:52, Warren Kumari wrote:
> >
>
> On Sep 27, 2016, at 2:38 PM, Jim Reid wrote:
>
> They both come up short as problem statements IMO. I’m struggling to find
> words to succinctly describe what problem the WG is expected to solve - sorry
> about that -- since it appears to be a layer 9+ matter. Both drafts seem to
> be conce
On Tue, Sep 27, 2016 at 2:38 PM, Jim Reid wrote:
>
>> On 27 Sep 2016, at 18:52, Warren Kumari wrote:
>>
>>> Meh. I wish the WG could stop the shed-painting on a frankly pointless
>>> detail and concentrate its efforts on producing a viable problem statement.
>>
>> we have two of them --
>
>
On Tue, Sep 27, 2016 at 3:28 PM, White, Andrew
wrote:
> Hi Shumon,
>
>
>
> True. When a resolver gets an NXDOMAIN for, say x.example.com, would it
> better to say the resolver SHOULD drop from cache all descendents of
> x.example.com, or MAY?
>
>
>
> It may be computationally expensive to search
On Tue, Sep 27, 2016 at 3:10 PM, Shumon Huque wrote:
> On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew
> wrote:
>
>> Hi Shumon,
>>
>>
>> What about this?
>>
>>
>>
>> # When an iterative caching DNS resolver receives a response with RCODE
>> being NXDOMAIN,
>>
>> # the resolver SHOULD store the re
Hi Shumon,
True. When a resolver gets an NXDOMAIN for, say x.example.com, would it better
to say the resolver SHOULD drop from cache all descendents of x.example.com, or
MAY?
It may be computationally expensive to search cache to remove cached NXDOMAIN
responses below x.example.com, and I see
On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew
wrote:
> Hi Shumon,
>
>
> What about this?
>
>
>
> # When an iterative caching DNS resolver receives a response with RCODE
> being NXDOMAIN,
>
> # the resolver SHOULD store the response in its (negative) cache. During
> the time the response
>
> # i
Hi Shumon,
What about this?
# When an iterative caching DNS resolver receives a response with RCODE being
NXDOMAIN,
# the resolver SHOULD store the response in its (negative) cache. During the
time the response
# is cached, any query with a QNAME at or descended from the denied name that
is n
I think Jim is on to some thing here. I suspect part of the problem is
that there is no crisp understanding of what the DNS actually is. Without
that it is much harder to say what it is not.
/Wm
On Tue, Sep 27, 2016 at 11:38 AM, Jim Reid wrote:
>
> > On 27 Sep 2016, at 18:52, Warren Kumari
On Tue, Sep 27, 2016 at 1:55 PM, Edward Lewis
wrote:
>
> I'd written up a response, but perhaps the intent of the text is fine.
> The way it is written is what is throwing me.
>
> Perhaps instead of this:
>
> # When an iterative caching DNS resolver receives a response NXDOMAIN,
> # it SHOULD
> On 27 Sep 2016, at 18:52, Warren Kumari wrote:
>
>> Meh. I wish the WG could stop the shed-painting on a frankly pointless
>> detail and concentrate its efforts on producing a viable problem statement.
>
> we have two of them --
Indeed Warren. That’s one too many.
They both come up sh
On 9/26/16, 20:49, "Mark Andrews" wrote:
>No. SHOULD is not MUST. Every SHOULD has a implict UNLESS
>. In this case we actually have a reason for
>the why the second and third SHOULD are not MUSTs.
>
>I could turn first SHOULD into a MUST and still reach the MAY.
I have to admit I
On Tue, Sep 27, 2016 at 10:25 AM, Jim Reid wrote:
>
>> On 27 Sep 2016, at 09:45, Ray Bellis wrote:
>>
>> Personally, I like the term.
>
> Meh. I wish the WG could stop the shed-painting on a frankly pointless detail
> and concentrate its efforts on producing a viable problem statement.
we
> On 27 Sep 2016, at 09:45, Ray Bellis wrote:
>
> Personally, I like the term.
Meh. I wish the WG could stop the shed-painting on a frankly pointless detail
and concentrate its efforts on producing a viable problem statement.
___
DNSOP mailing list
Hello Paul,
On 26 Sep 2016, at 16:32, Paul Hoffman wrote:
On 26 Sep 2016, at 0:33, Peter van Dijk wrote:
2308 does not “redefine” QNAME. It clarifies that the usage in
1034 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not
conflict with this; the QNAME there is just the initial Q
On 27/09/2016 09:33, hellekin wrote:
> I remember introducing the term 'pseudo-TLD' in the P2P Names draft and
> doing a similar research as the one I cut from your message for brevity.
> At the time I thought the Canada Dry effect would work: it looks like
> DNS, it tastes like DNS, but it's n
On 09/27/2016 02:37 AM, Warren Kumari wrote:
>
> My opinion really doesn't matter, but I happen to think that, at this
> point, we should evaluate the requested P2P names according to RFC
> 6761 -- you followed the process in effect *at the time*, and jumped
> through many hoops. The process is f
19 matches
Mail list logo
