On Tue, Jan 7, 2020 at 6:18 PM Paul Hoffman wrote:
> On Jan 7, 2020, at 6:03 PM, Joe Abley wrote:
> > I don't object to the intended status (standards track). There are
> reports of multiple independent implementations included in the document,
> which seems pleasing and proper.
>
> Definitely p
On Jan 7, 2020, at 6:03 PM, Joe Abley wrote:
> I don't object to the intended status (standards track). There are reports of
> multiple independent implementations included in the document, which seems
> pleasing and proper.
Definitely proper. The calls for making this RFC "experimental" go aga
Hi Tim,
On 4 Jan 2020, at 17:30, Tim Wicinski wrote:
This starts a Working Group Last Call for "Message Digest for DNS
Zones"
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/
The Current Intended Status of this document is: *
> On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote:
>
This specification utilizes ZONEMD RRs located at the zone apex.
Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
specification.
>>> Instead - "non-apex ZONEMD RRs MUST be ignored by the recei
> On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote:
>
>>
>>
>>> 5) 3.1.2 - This is I believe different than how DNSSEC does it? If it's
>>> the same, then this is fine, otherwise this protocol should be calculating
>>> the RRSet wire representation the same as DNSSEC does it.
>> In my exp
> On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote:
>
> As I suggested in one of my messages, giving an idea of how long it takes to
> digest various sizes of zones given commodity hardware would be a good start.
> Going on and talking about the ratio of that time to the typical update
>
[ Note to readers: Section 10.1 ("Issue Fixed in this Document") is useful to
understand the reason for this document. I'm asking the authors to please put a
pointer (or similar) to this in the abstract. ]
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to con
Dear draft-ietf-dnsop-rfc2845bis authors,
I've just kicked off IETF FC for this document - while performing my
AD review, I kept wondering "Why a -bis, what changed?", and then I
discovered "10.1. Issue Fixed in this Document", and I suddenly
remembered / understood. When you next revise the docu
On Tue, Jan 07, 2020 at 02:54:43PM +, Tony Finch wrote:
> The third paragraph of the abstract suggests this is relevant to DNSSEC
> RSASHA1:
>
> https://eprint.iacr.org/2020/014
[ I've Bcc'd the authors, perhaps they'll follow up with a comment, or
reply to me off-list with permission to
On 12/23/19 9:22 PM, Eric Orth wrote:
> 2) Any chain limiting enforcement only applies to stubs following
> chains, not recursives.
>
> Recursives are already following CNAMEs without a standardized limit.
> [...]
(I'm a bit late, I'm sorry.) Recursives *in practice* seem quite
limited. Unbound
The third paragraph of the abstract suggests this is relevant to DNSSEC RSASHA1:
https://eprint.iacr.org/2020/014
> SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and
> Application to the PGP Web of Trust
> Gaëtan Leurent and Thomas Peyrin
> Abstract: The SHA-1 hash function was d
On 1/7/20 3:15 AM, Michael StJohns wrote:
>>>
>>> 1) A recommendation for the maximum size of the zone [...]
>> I am reluctant to add this. As John said, I think it won't age well.
>> [...]
>
> As I suggested in one of my messages, giving an idea of how long it
> takes to digest various sizes of z
12 matches
Mail list logo
