On Feb 21, 2019, at 2:24 PM, Mark Andrews wrote:
> Implementation details are beyond the scope of RFCs.
Indeed they are. My point is that if you want to be careful of memory usage or
disk usage, you can be—there is no need to use a hash. In essence, requiring
us to use a hash is specifying
> On 22 Feb 2019, at 9:52 am, Joe Abley wrote:
>
> On 21 Feb 2019, at 14:34, Mark Andrews wrote:
>
>> Machines die. Machines are unplugged. Server are unreachable at critical
>> times. Externally driven cleanup can never be reliable.
>
> I'm not disputing any of that. I guess my first
On Feb 21, 2019, at 2:52 PM, Joe Abley wrote:
> The master could apply policy based on criteria like owner name pattern
> matching or source of the update. Garbage collection might not happen with
> the kind of split-second accuracy that I sense this mechanism's proponents
> are suggesting,
On 21 Feb 2019, at 14:34, Mark Andrews wrote:
> Machines die. Machines are unplugged. Server are unreachable at critical
> times. Externally driven cleanup can never be reliable.
I'm not disputing any of that. I guess my first question was first whether
cleanup is necessary, and second
> On 22 Feb 2019, at 8:02 am, Ted Lemon wrote:
>
> On Feb 21, 2019, at 11:24 AM, Mark Andrews wrote:
>> Ted. It has to work post zone transfer.
>
> That’s not a problem, since the representation would be more compact, but
> would not be lossy: the interchange through the zone transfer would
On Feb 21, 2019, at 11:24 AM, Mark Andrews wrote:
> Ted. It has to work post zone transfer.
That’s not a problem, since the representation would be more compact, but would
not be lossy: the interchange through the zone transfer would be the same
regardless of how the data is stored.
Ted Lemon wrote on 2019-02-21 11:11:
On Feb 21, 2019, at 11:05 AM, Mark Andrews wrote:
Hashes save space once the rdata is bigger than the hash.
Agreed, but why do we need to save space? It would be possible to
have the data structure that stores the delete RR point to the RR
that’s to be
Machines die. Machines are unplugged. Server are unreachable at critical
times. Externally driven cleanup can never be reliable.
--
Mark Andrews
> On 22 Feb 2019, at 06:21, 神明達哉 wrote:
>
> At Wed, 20 Feb 2019 07:51:51 -0500,
> Joe Abley wrote:
>
> > The crux of the use case seems to be
Ted. It has to work post zone transfer.
Mark
--
Mark Andrews
> On 22 Feb 2019, at 06:11, Ted Lemon wrote:
>
>> On Feb 21, 2019, at 11:05 AM, Mark Andrews wrote:
>> Hashes save space once the rdata is bigger than the hash.
>
> Agreed, but why do we need to save space? It would be possible
At Wed, 20 Feb 2019 07:51:51 -0500,
Joe Abley wrote:
> The crux of the use case seems to be that it is commonplace for names in
the DNS to exist for short periods of time and that for some applications a
name that overstays its welcome can cause an operational problem.
>
> While I can understand
On Feb 21, 2019, at 11:05 AM, Mark Andrews wrote:
> Hashes save space once the rdata is bigger than the hash.
Agreed, but why do we need to save space? It would be possible to have the
data structure that stores the delete RR point to the RR that’s to be deleted,
so if on-disk or in-memory
On Thu, 21 Feb 2019 at 12:25, Tony Finch wrote:
> Mark Andrews wrote:
> > > On 21 Feb 2019, at 6:30 am, Tony Finch wrote:
> > >
> > > Does it need to be per-record? Why not GC the whole RRset?
> >
> > Because there are scenarios where you do want to GC as single
> > record from the RRset. AD
Mark Andrews wrote:
> > On 21 Feb 2019, at 6:30 am, Tony Finch wrote:
> >
> > Does it need to be per-record? Why not GC the whole RRset?
>
> Because there are scenarios where you do want to GC as single
> record from the RRset. AD has them with SRV. Each server adds
> its own SRV record to the
13 matches
Mail list logo
