From: Tim Wicinski
Date: 2018-07-30 10:11
To: John Levine
CC: Evan Hunt; dnsop
Subject: Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
>
> I had spent some time looking the draft over and realizing it was marked
> standards track, and I think it would be easier to adopt for
I agreee John.We have plenty of RR Types to hand out. especially at the
upper end
On Sun, Jul 29, 2018 at 10:30 PM, John R Levine wrote:
> Sorry, if that's what it sounded like. I also think it's worth
> considering. My point is that if it's worth trying, we should give it an
> rrtype and no
Sorry, if that's what it sounded like. I also think it's worth
considering. My point is that if it's worth trying, we should give it an
rrtype and not screw around with overloaded TXT records. It's not like
we're in any immediate danger of running out of rrtypes.
R's,
John
My email wasn't
Joe
My email wasn't a statement that I don't think the work is relevant. It
seems that interesting enough for the WG that there are
two use cases: 1) the root zone; and 2) everything else.
I had spent some time looking the draft over and realizing it was marked
standards track, and I think it wou
In article <20180730002348.ga41...@isc.org> you write:
>A good point. Technically, I don't think there's anything in ZONEMD that
>couldn't be implemented with TXT; using a dedicated rrtype for the purpose
>is mere convenience.
Well, heck, we could do the whole DNS with TXT records. But if it
were
> On 30 Jul 2018, at 10:23 am, Evan Hunt wrote:
>
> On Sun, Jul 29, 2018 at 05:42:04PM -0400, Joe Abley wrote:
>> I also agree with Tim's observation the other day that if this is just a
>> new RRType, then expert review is all that is procedurally required and
>> it'd be a generous extension
On Sun, Jul 29, 2018 at 05:42:04PM -0400, Joe Abley wrote:
> I also agree with Tim's observation the other day that if this is just a
> new RRType, then expert review is all that is procedurally required and
> it'd be a generous extension of what is required to document the
> implementation and use
I realize that hypothetically a malicious server could send you a large
file of garbage. ...
A lot of other updaters use HTTPS, which does not have this issue if
the terminating party is also the source of the data. ...
Doesn't that assume that the other server will never be compromised? I
On Jul 29, 2018, at 17:13, Florian Weimer wrote:
> * Tim Wicinski:
>
>> For the ZONEMD RR Type, where in the registry do the authors think it
>> should go? While some of that falls on the Expert Review process, I think
>> the document authors should capture their rationale in the document. If
Hi Steve,
I fully agree that the kinds of things I was waving my hands about are science
projects at best, and so far from ready for informed standardisation in dnsop
that it seems silly even typing that phrase.
However, you were speculating about the future in your reaction to some of the
com
* Tim Wicinski:
> For the ZONEMD RR Type, where in the registry do the authors think it
> should go? While some of that falls on the Expert Review process, I think
> the document authors should capture their rationale in the document. If
> the proposed RR Type is greater than 256 (which I think
* John R. Levine:
> On Sat, 28 Jul 2018, Florian Weimer wrote:
>> A malicious server might never stop sending data, or claim that the
>> transfer is ridiculously large. If the zone digest does not include
>> information about the amount of data, this can only be detected after
>> the server ended
On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote:
> You need to know the hash is valid before you start the download.
> Therefore the hash has to be signed.
Before you *start* the download? Or before you use what you downloaded?
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium
Joe,
Thanks. You've mentioned several things tagged with "it would be nice to
have." Each of these has both (a) one or more assumptions about a problem
that seeking to be addressed and (b) the implication of a fairly massive
architectural change. These need a deeper and better organized discuss
Hi Steve,
On Jul 29, 2018, at 15:09, Steve Crocker wrote:
> As an individuals, you, I, or anyone else, can do whatever we like, of
> course. On the other hand, as system designers we presumably look at the
> overall system and try to put in place an operational structure that
> anticipates a
Joe,
As an individuals, you, I, or anyone else, can do whatever we like, of
course. On the other hand, as system designers we presumably look at the
overall system and try to put in place an operational structure that
anticipates and meets the likely needs of the users.
The present and long-stan
Hi, Benjamin,
On Fri, Jul 27, 2018 at 12:33 PM Benjamin Kaduk wrote:
> On Thu, Jul 26, 2018 at 09:33:20PM -0700, Spencer Dawkins wrote:
> > --
> > COMMENT:
> >
On Jul 29, 2018, at 12:19, Steve Crocker wrote:
> It feels like this discussion is based on some peculiar and likely incorrect
> assumptions about the evolution of root service. Progression toward hyper
> local distribution of the root zone seems like a useful and natural sequence.
> However
Alexey Melnikov has entered the following ballot position for
draft-ietf-dnsop-session-signal-12: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please re
It feels like this discussion is based on some peculiar and likely incorrect
assumptions about the evolution of root service. Progression toward hyper
local distribution of the root zone seems like a useful and natural sequence.
However, the source of the copies of the root zone will almost ce
In article you write:
>Mail headers doesn’t have NSEC records. Also any operation where you need to
>reconstruct the file by combining bits from
>different places/channels is prone to errors.
>
>You need to know the hash is valid before you start the download. Therefore
>the hash has to be sign
Mail headers doesn’t have NSEC records. Also any operation where you need to
reconstruct the file by combining bits from different places/channels is prone
to errors.
You need to know the hash is valid before you start the download. Therefore the
hash has to be signed.
O.
--
Ondřej Surý — ISC
22 matches
Mail list logo
