Thanks for calming fears. With "..document asks the question of whether it is
time to either redesign and replace the DNS.." in the abstract of a doc by
Klensin, I was a bit worried. -Rick
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Hoffman
> Se
Good catch. Thanks for identifying this and making it signed by both. -Rick
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews
> Sent: Saturday, July 29, 2017 5:39 PM
> To: Tony Finch
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] CDS/CDNSKEY RRSet
+1 to all from frmr usgovie. We ain't that clever.
On Wednesday, March 22, 2017, Jim Reid wrote:
>
> > On 21 Mar 2017, at 14:53, Suzanne Woolf > wrote:
> >
> > RFC 3172 was written in 2001…
>
> RFC 3172 was an attempt to rewrite history and contrive an acronym:
> Address and Routing Parame
Just to complete the thought. As promised here’s the link to my demo
implementation. https://www.co.tt/cdstest.cgi -Rick
From: Richard Lamb
Sent: Wednesday, April 6, 2016 9:34 AM
To: 'Ólafur Guðmundsson' ; Tim Wicinski
Cc: dnsop
Subject: RE: [DNSOP] Working Group Last Call for
Olafur-
Read it. Liked it. No changes needed. Now implementing it.
Thank you for doing this and finishing/clarifying the CDS work. Will send you
a note when I have things running.
-Rick
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Ólafur Guðmundsson
Sent: Sunday, April 3, 2016 8
Given that there are least three implementations based on this draft in
widespread use, IMHO, I believe this draft should move forward as is. As
mentioned below, a stable reference would be useful for implementers like
myself. -Rick
-Original Message-
From: DNSOP [mailto:dnsop-boun...
Sheesh..I thought we were talking about engineering issues.
Speaking only as the humble engineer who helped develop the publication methods
and wrote the software that generates all the pieces, the most recent draft
does describe what my programs, scripts, and other pieces do. If there is any
I have carefully read this draft and now have implemented its contents
twice. Once at the root and now on a root key rollover test setup*. The
draft looks good to me.
-Rick
* http://icksk.dnssek.info/fauxroot.html
___
DNSOP mailing list
DNSOP@ietf.org
FWIW, I agree w/ Paul and Ted. Customer should have the option to fill in
reverse IPv6 tree.
Arent we headed toward a society where we all become content providers with
"the cloud" just a recurring fad?
-Rick
-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of
Fwiw i believe there is a clear need for this work. Having been involved
with various early DNSSec deployment efforts, the diminished value of ixfr
has resulted in a few different home grown hybrid solutions to capture the
efficiency of rsync with added notification functionality. It would be
goo
Speaking for myself:
First: Thank you Jim and Joe for seeking to increase the signal-to-noise ratio
on this thread and for explaining what the attack vector would be for lower IQ
folk like myself.
Second: I have always taken my instructions from the community. So regardless
of what I believe
Thank you guys!
This is exactly the kind of leadership the rest of the IT industry needs to
help take DNSSEC to the next level. Many of us were just going to hack up some
code for Windows out of frustration but were stymied by what sort of interface
would be the most attractive to developers (
Here are updates from the recent ICANN BA meeting.
http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-dnssec-ssac-key-rollover-20nov13-en.pdf
http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-root-zone-ksk-20nov13-en.pdf
-Original Message-
From: DNS
FWIW I don't see any problem with having RRtypes for MAC addresses in the DNS.
I am not an old DNS salt like many on this list, but seems there are many other
RRtypes out there that have less interest. I see the reference to the IEEE
"Guidelines for use of a ...EUI-48" but for the sake of equa
Jason-
FWIW: The -04 draft looks good. It is clear and well written and I think it is
a valuable resource.
As I am late to looking at this draft please take this only as a comment from a
narrow minded engineer ;-) After the rationale, explanations and caveats I
kept looking for how to implem
I've reviewed it and have nothing to add. I find it very useful and support it
being published as Informational.
-Rick
> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
> Stephen Morris
> Sent: Monday, June 13, 2011 10:23 AM
> To: dnsop@ie
Good point. Make it adaptive.
> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
> Paul Hoffman
> Sent: Thursday, June 02, 2011 8:43 AM
> To: Joe Abley
> Cc: IETF DNSOP WG
> Subject: Re: [DNSOP] watching for signature expiration in zones you d
I still think, stale or not, having some idea of what the zone's policy is
regarding signature updates would be useful. I've been running signature
expiry monitoring scripts for a few years and having some idea of what is "ok"
for a zone would be very helpful - particularly those zones that hav
IMHO since the DPS is the only public document , section 4.4 and its DR aspects
should be in the DPS to at least indicate to the public that these issues have
been considered.
4.8 ought to be there as an optional reminder for those writing such a
framework.
-Rick
> -Original Message
> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
> Of Olaf Kolkman
> Sent: Thursday, January 21, 2010 3:42 AM
> To: dnsop WG
> Subject: Re: [DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-
> rfc4641bis-01.txt
>
>
> In trying to get a reasona
A very useful piece of work. Particularly the material on emergency key
rollover. It took me some time to write the scripts to take into account TTL,
propagation delays, and various key compromise scenarios. The approach your
work takes gives the implementer a clear framework. Wish I had your
Another 10 year delay would benefit all our respective businesses ;-) But to
move forward you sometimes have to take chances.
-Rick
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Ulevitch
Sent: Tuesday, August 19, 2008 9:09 AM
To: David Conrad
Cc:
22 matches
Mail list logo
