Hi Mark,
On 11/09/09 4:47 PM, Mark Andrews ma...@isc.org wrote:
Publish new DNSKEY, publish new DS, wait at least the max TTL of
the old DS/DNSSKEY TTLs. Remove old DS, remove old DNSKEY.
The same thing should be happening with ITAR. Publish new DNSKEY,
publish new DS, wait the
Kim,
could the ITAR have a serial number that could be checked without
having to download and parse the whole file, to enable quick checks
from consumers of the ITAR information that would not overwhelm either
end of the communication?
Joao
PS: or even, could it be published as a DNS zone
Hi Joao,
On 14/09/09 9:53 AM, joao damas j...@bondis.org wrote:
could the ITAR have a serial number that could be checked without
having to download and parse the whole file, to enable quick checks
from consumers of the ITAR information that would not overwhelm either
end of the
I want to propose a new term for describing certain relationships in a
network model. The term is Proof Source Provider or PSP and it means
some service which is providing a trust-anchor for some other process or
the like.
It pertains then to auditing trust relationships and their ability to
On Sep 14, 2009, at 12:01 PM, Kim Davies wrote:
Hi Mark,
On 11/09/09 4:47 PM, Mark Andrews ma...@isc.org wrote:
Publish new DNSKEY, publish new DS, wait at least the max TTL of
the old DS/DNSSKEY TTLs. Remove old DS, remove old DNSKEY.
The same thing should be happening with ITAR.
David Blacka wrote:
I think it works to simply say this:
* The ITAR should be checked for changes once per 24 hour period.
Then:
* TLD operators would know to pre-publish the new DS at least 24
hours before doing the KSK roll.
But without any timing advice, it is quite difficult for
At 14:45 -0400 9/14/09, David Blacka wrote:
I think it works to simply say this:
* The ITAR should be checked for changes once per 24 hour period.
Then:
* consumers (e.g., dlv.isc.org, me) will know to check at least
once per day;
* TLD operators would know to pre-publish the new DS
In message c6d3b6d8.15d4d%kim.dav...@icann.org, Kim Davies writes:
Hi Mark,
On 11/09/09 4:47 PM, Mark Andrews ma...@isc.org wrote:
=20
Publish new DNSKEY, publish new DS, wait at least the max TTL of
the old DS/DNSSKEY TTLs. Remove old DS, remove old DNSKEY.
=20
The same thing should
In message a06240800c6d44242f...@[10.31.200.153], Edward Lewis writes:
At 14:45 -0400 9/14/09, David Blacka wrote:
I think it works to simply say this:
* The ITAR should be checked for changes once per 24 hour period.
Then:
* consumers (e.g., dlv.isc.org, me) will know to check
