-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alfred,
I have no further comments on part (A). I have also adopted the
leftovers in part (B), with explanation in between lines.
Best regards,
Matthijs
On 04/11/2012 10:08 PM, Alfred � wrote:
Matthijs, again thanks for your quick and detailed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Marc,
Coming back to your review items, I only think point 1 is not decided
on yet. But I don't think this should stop progress.
You can find my responses in between lines.
Best regards,
Matthijs
On 04/03/2012 11:11 AM, Marc Lampo wrote:
Hello Matthijs,
Regarding 1 - ... no relationship ... validating ...
Suggestion (a phrase that does not hint at any possible relationship) :
This document holds no information that applies to the configuration
of validating recursive name servers (validators).
Ok regarding 2 : three stages
OK
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/2012 12:48 PM, Marc Lampo wrote:
Hello Matthijs,
Regarding 1 - ... no relationship ... validating ...
Suggestion (a phrase that does not hint at any possible
relationship) : This document holds no information that applies
to the
Hello,
this is not a reply to any comment already made on this approach
of negative trust anchors.
(I just posted a reply with RFC4641bis in the subject, about this)
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/2012 02:09 PM, Marc Lampo wrote:
Hello all,
(This also concerns the other discussion about Negative Trust
Anchors, I'll post with that subject as well)
-Original Message- From: Matthijs Mekking
[mailto:matth...@nlnetlabs.nl]
Moin!
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of DNSSEC.
The alternative is to have a parent regularly (no frequency defined)
check the coherence of DS
Mark,
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of DNSSEC.
The alternative is to have a parent regularly (no frequency defined)
check the coherence of
On Thu, Apr 12, 2012 at 08:27:21AM -0600, Stephan Lagerholm wrote:
Specifically in this case, you are assuming that the parent knows the
algorithms used for the DS record. He would have to in order to
validate. That might not always hold true. Additionally, the record is
not 'yours', it is
Joe Abley joe.ab...@icann.org writes:
On 2012-04-11, at 12:09, Wes Hardaker wrote:
NTA example.com Thu Apr 12 09:06:42 PDT 2012
I realise this is just a thought experiment
Well, true it certainly is. And in fact the above thought experiment
wasn't meant to imply a resource record, but
Paul Wouters p...@nohats.ca writes:
On Wed, 11 Apr 2012, Shane Kerr wrote:
Disabling DNSSEC validation for broken domains seems completely
rational, at least for some types of brokenness.
So someone will make a browser plugin to enable this. Let them.
In our validation work within firefox
In message dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com,
Steph
an Lagerholm writes:
Mark,
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of
Mark Andrews Thursday, April 12, 2012 6:10 PM:
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of DNSSEC.
The alternative is to have a parent
In message dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com,
Steph
an Lagerholm writes:
Mark Andrews Thursday, April 12, 2012 6:10 PM:
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating
I think this is a good draft.
I do have one comment, based on experimenting with both encoding a /16 in DNS
zone files and the resulting lookups on those IP prefixes contained under it.
As this document progresses I would very much like to advocate that the WG
considers picking a single
15 matches
Mail list logo
