sounds like a delightful session with some productive ideas.
On Wed, Jul 24, 2019 at 5:23 PM Paul Vixie wrote:
> one other matter emerged during this discussion. path mtu discovery is
> dead at
> the moment, for valid security reasons. however, a jumbogram sized campus
> can
> be described in s
On Thursday, 25 July 2019 05:44:50 UTC Evan Hunt wrote:
> ...
>
> But, it's Mostly Harmless. The implementation cost can be zero if you want
> it to be; it's just a server configuration. At worst, it's a waste of the
> time that's been spent talking about it (with the zone transfer code that
> f
On Tue, Jul 23, 2019 at 10:18:20PM +, Paul Vixie wrote:
> at the one-hour DNSOP meeting in montreal on monday evening, the authors
> of RFC 7706 described some of the use case questions they were hoping to
> answer in their -bis document, and one of them hit squarely on a topic i
> spoke about
one other matter emerged during this discussion. path mtu discovery is dead at
the moment, for valid security reasons. however, a jumbogram sized campus can
be described in static routes, using MTU 1500 only for "default". and also,
any future path mtu discovery functions will, as in the past, s
with four of us in attendance monday evening, i presented my appreciation for
fujimora-san's draft and admitted that EDNS0 ought to have required DF and
ought to have used examples which would fit in a then-common MTU 1500 network.
i then asked that numbers like 1220, 1280, 576, and 1500 not be
On Tue, 2 Jul 2019, Matthijs Mekking wrote:
Here's a draft with discussion why also the protocol should go
away. We would like to hear what you think about it.
The discussion of the private network use case in section 2 has two
minor errors plus one bit that is unclear.
When we designed DLV
Thank you both.
On Wed, Jul 24, 2019 at 6:29 PM Matthijs Mekking
wrote:
> RFC 4035 says:
>
>If the resolver accepts the RRset as authentic, the validator MUST
>set the TTL of the RRSIG RR and each RR in the authenticated RRset to
>a value no greater than the minimum of:
>
>o the
On 21-07-19 16:26, Puneet Sood wrote:
> * The experiment was run from Princeton, New Jersey in Northeast US.
> The location is in a very well connected part of the world between
> network peering points in NYC and Washington DC. You will not see much
> difference (due to network latency) between th
On Mon, Apr 29, 2019 at 05:00:38PM -0700,
internet-dra...@ietf.org wrote
a message of 41 lines which said:
> Title : Terminology for DNS Transports and Location
> Author : Paul Hoffman
> Filename: draft-hoffman-dns-terminology-ter-01.txt
Seen o
Sorry, I meant approx. 10 minutes into the meeting: 10:10am, not 9:10am.
On Wed, Jul 24, 2019 at 1:42 PM Dave Plonka wrote:
>
> Hi folks,
>
> Note that the MAPRG agenda has changed moving this DNSSEC-related
> topic from last to first, approx. 0910, to accommodate the schedule of
> the presenter
Hi folks,
Note that the MAPRG agenda has changed moving this DNSSEC-related
topic from last to first, approx. 0910, to accommodate the schedule of
the presenter in their distant timezone. :)
* Understanding Evolution and Adoption of Top Level Domains and DNSSEC
The meeting's full agenda includin
Paul Vixie wrote:
>
> first, all complexity comes at a cost. the new code and configuration needed
> to support "mirror zones" will be a life long source of bugs and
> vulnerabilities, because that's true of every new feature. the desired benefit
> should be weighed against this cost. "by running
Hello DNSOP,
On 7/15/19 10:00 PM, Benno Overeinder wrote:
> This starts a Call for Adoption for:
> draft-lhotka-dnsop-iana-class-type-yang
I support adoption of this draft, the idea is non-controversial. I
believe the comments that have been made can be worked out and I believe
the YANG/NETCONF e
> On Jul 22, 2019, at 8:37 PM, Normen Kowalewski wrote:
>
> While I agree that “add” today covers discussion around the case described in
> here, but the reason that it covers it is because “add” acts as a "catch all
> bucket" for “various DNS things not well defined”.
> If we want to cover
14 matches
Mail list logo
