This is why rfc 2308 definition of qname is correct.
On August 24, 2017 9:46:58 AM MDT, Hector Santos wrote:
>I have a question related to RFC2317 "Classless IN-ADDR.ARPA
>delegation."
>
>Earlier this year, I switched from a class C bank of 256 addresses to
>a reduced set of 32 ips (/27). To g
We might want to invent a new term here like effective qname, but basically I
agree with Mark. 2308 was written after bind itself learned the distinction.
On August 24, 2017 3:27:34 PM PDT, Mark Andrews wrote:
>
>RFC 2308 is consistent with RFC 1034.
>
>Go read *all* of RFC 1034. QNAME is used
On September 22, 2017 9:58:42 AM EDT, Andrew Sullivan
wrote:
>On Thu, Sep 21, 2017 at 07:31:29PM -0700, Paul Vixie wrote:
>
>[…]
>
>> we need a kernel option for various open source operating systems
>which
>> causes all UDP to be fragmented at 512 octets of payload.
>
>If working on a protocol
On November 14, 2017 9:13:29 PM PST, Dave Lawrence wrote:
>Paul Vixie writes:
>> i'm of the opposite view. we should not change behaviour without
>> explicit signaling. if that means it takes 10 years to reach 50%
>> penetration, like EDNS did, then that's the cost of doing business.
>
>Just s
Exactly.
On November 27, 2017 9:22:51 PM GMT+08:00, Tony Finch wrote:
>Joe Abley wrote:
>> On Nov 23, 2017, at 12:44, Tony Finch wrote:
>>
>> > It's quite difficult to have multiple masters and DNSSEC and
>coherent
>> > copies of the zone from all masters - i.e. more effort than just
>spinning
1034 cannot be reasonably read that way. I am asking for a clarification not a
rule change.
On November 29, 2017 8:21:01 PM GMT+08:00, Andrew Sullivan
wrote:
>On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote:
>> that's fatally unclear.
>
>So I gather :)
>
>> then the thing to say wou
nt of the
existing document then please write nothing at all.
On November 29, 2017 8:28:11 PM GMT+08:00, Andrew Sullivan
wrote:
>On Wed, Nov 29, 2017 at 12:23:36PM +0000, P Vix wrote:
>> 1034 cannot be reasonably read that way.
>
>Sure it can. See the discussion in draft-sullivan-d
No cc. I call them full resolved not recursive resolvers. I thought 1034 also
did.
On March 12, 2018 3:09:27 PM UTC, Paul Hoffman wrote:
>Greetings. The definition of "recursive resolver" has been problematic
>both in RFC 7719 and in draft-ietf-dnsop-terminology-bis. Section 6 of
>draft-ietf-d
When Ed have up defending the qtuple, complexity moved in.
On March 20, 2018 4:04:31 PM UTC, Joao Damas wrote:
>Camels are indeed great animals and they can be loaded until eventually
>one more insignificant straw breaks their back. I guess that is were
>Bert thinks the DNS is at now and I don’t
Harmonization for the sake of harmonization is bad, and very little Internet
System technology gets it. Just do new stuff better.
On March 20, 2018 6:11:08 PM UTC, "John R. Levine" wrote:
>After some back and forth with Dave, I realized I missed what seems to
>be
>to be a large change: this dra
Did you hear the part about doing it the way we did when deprecation iquery?
There's a discovery and decision process that involves the broader community.
Technical merit was provided. Sad that I can't think of a way to do it more
clearly.
On March 23, 2018 7:18:25 PM UTC, "Ondřej Surý" wrote:
Other parts of the doc say that some rr types are class specific and others are
universal. There an implication that class affects rdata format within a
universal rr type. It's incoherent as hell. The reason we don't use it is it's
poor definition. Incompatible implmentations could all be right
I agree to review and comment. Note that I am provisionally negative to the
idea itself, and my review may reflect that. Vixie
On March 27, 2017 4:56:58 PM CDT, Dave Lawrence wrote:
>One of the two drafts I wanted to talk about at dnsop today for WG
>adoption was "Serving Stale Data to Improve D
I accept Warren's alternative wording. Any of them.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
+1
On July 11, 2017 3:17:57 PM GMT+08:00, "Petr Špaček" wrote:
>Hello dnsop,
>
>reading throught the latest version, I object to the proposed TLV
>format.
>
>I feel that implications from switch to non-RR format are
>underestimated
>and following e-mail attempts to explain why I believe it is a b
15 matches
Mail list logo
