On 8/29/2024 9:14 PM, Warren Kumari wrote:
Yes, I might *personally* decide to use the IANA TA after the
validUntil if they haven't published a new one. If I did, that would
be entirely my own (bad) decision, and I'm clearly doing something
unsupported… just like if I happen to eat a can of bea
On 8/29/2024 4:24 PM, Paul Hoffman wrote:
On Aug 27, 2024, at 16:46, Warren Kumari wrote:
Thank you very much for your comments. We've had some discussions, and the
authors will be publishing a new version in the next few days addressing these.
As you can see, we have turned in -05. We think
Hi Warren -
Inline -
On 8/21/2024 6:12 PM, Warren Kumari wrote:
On Wed, Aug 21, 2024 at 10:28 AM, Edward Lewis
wrote:
On Aug 20, 2024, at 20:42, Michael StJohns mailto:m...@nthpermutation.com>> wrote:
... trimmed ...
But this document is not a pure protocol-de
Hi Ed -
Thanks for a thoughtful reply. Notes in line.
On 8/21/2024 10:28 AM, Edward Lewis wrote:
On Aug 20, 2024, at 20:42, Michael StJohns wrote:
Hi Paul -
I'm confused from your responses below - is this a WG document where the WG
gets to decide, or is this an IANA document (lik
ion."
/msj/
On 8/20/2024 6:20 PM, Paul Hoffman wrote:
This is an omnibus reply to the messages on this thread. I believe that the -04
draft is complete, but responses to the replies below may change that. The
draft is currently in Warren's hands, so he gets to decide whether a n
s that chain to
this TA that are otherwise valid, as valid regardless of the validFrom
date". e.g. We're not requiring a DNS implementation to track date/times
outside of the DNSSEC protocol.
Trimming...
On 8/15/2024 4:58 AM, Petr Špaček wrote:
On 10. 08. 24 17:21, Michael StJohns wr
Hi Peter - continues below.
On 8/15/2024 5:41 AM, Peter Thomassen wrote:
Hi Mike,
On 8/10/24 17:21, Michael StJohns wrote:
Paul - this is related directly to the newly specified inclusion of
the public key material in this draft (sect 3.2 last para):
A KeyDigest element can contain
Hi Paul -
Inline
On 8/9/2024 5:09 PM, Paul Hoffman wrote:
On Aug 9, 2024, at 12:16, Michael StJohns wrote:
Two comments - one major and one very minor.
Major: I'm sorry for the late comment, but I didn't realize you were planning on
starting to provide prospective DS's
Two comments - one major and one very minor.
Major: I'm sorry for the late comment, but I didn't realize you were
planning on starting to provide prospective DS's for unpublished keys.
Telling people there's a new trust anchor, and that the live key matches
this file is one thing - easy enou
After reading the thread, I'm confused as to why there's any question as
to adoption. This is an independent submission replacing an independent
submission, and is directive only on ICANN and explanatory for everyone
else.
Section 5 has "This document describes how DNSSEC trust anchors for th
On 7/18/2023 8:42 PM, George Michaelson wrote:
I know, I could submit these to the PSL website directly. I am asking
a meta question: do we think that operationally, if a PSL exists, that
all ccTLD and TLD should be on it?
The following ccTLD are in ISO3166 but not in the PSL:
bd
bl
bq
On 8/19/2022 3:30 PM, Paul Hoffman wrote:
DNS resolvers that serve the DNS protocol and non-DNS protocols at
the same time MUST resolve .alt names using the non-DNS protocols.
It was written the current way as a way to alert developers who are using the
Locally-Served DNS Zones registry t
On 8/15/2022 12:17 PM, Wes Hardaker wrote:
Paul Wouters writes:
This is why I also think 8624bis is better than a stand-alone document,
as it takes into account security effects, market deployment, and
trying to push the deployments to where we want it to go, instead of just
issuing a document
Disregard this - it was targeted for a different adoption call.
Thanks to Paul H for noticing.
Mike
On 7/12/2022 12:51 PM, Michael StJohns wrote:
On 7/12/2022 9:54 AM, Tim Wicinski wrote:
This starts a Call for Adoption for Negative Caching of DNS
Resolution Failures
The draft is
Let's try and attach the comment to the right call... *sigh*. See below.
On 7/12/2022 9:29 AM, Tim Wicinski wrote:
This starts a Call for Adoption for Survey of Domain Verification
Techniques using DNS
The draft is available here:
https://datatracker.ietf.org/doc/draft-sahib-domain-verific
On 7/12/2022 9:54 AM, Tim Wicinski wrote:
This starts a Call for Adoption for Negative Caching of DNS Resolution
Failures
The draft is available here:
https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/
Please review this draft to see if you think it is suitab
On 7/10/2022 12:30 PM, Dmitry Belyavsky wrote:
Section 10: "
Sorry, didn't get :(
I hope this helps -
Mike
Oops. My fault, and I never went back to expand on the omission.
Basically, section 10 has TBA1 and TBA2 for two code points, but you use
actual values for your examples
sages in that
paragraph are poorly constructed.
Later, Mike
On 7/8/2022 8:49 AM, Bob Harold wrote:
On Thu, Jul 7, 2022 at 6:21 PM Michael StJohns
wrote:
On 7/7/2022 5:32 AM, Willem Toorop wrote:
Dear dnsop,
This draft describes a mechanism for automatic provisioning of zones
On 7/7/2022 5:32 AM, Willem Toorop wrote:
Dear dnsop,
This draft describes a mechanism for automatic provisioning of zones
among authoritative name servers by way of distributing a catalog of
those zones encoded in a regular DNS zone.
The version's focus was finalizing for Working Group Last Ca
Hi Benno -
On 7/7/2022 3:12 PM, Benno Overeinder wrote:
Hi Mike,
On 07/07/2022 20:26, Michael StJohns wrote:
On 7/7/2022 12:28 PM, Benno Overeinder wrote:
Conducting a survey (2 times now) has worked well over the past 1.5
years to prioritise finishing existing work and starting new work
Hi Benno -
On 7/7/2022 12:28 PM, Benno Overeinder wrote:
Hi Mike,
On 07/07/2022 17:21, Michael StJohns wrote:
On 7/7/2022 11:10 AM, Benno Overeinder wrote:
It helps us and the WG itself to prioritise WG activities and start
a regular WG call for adoption of a number of documents. We will
Hi Benno -
On 7/7/2022 11:10 AM, Benno Overeinder wrote:
Hi Paul,
On 07/07/2022 16:58, Paul Hoffman wrote:
On Jul 7, 2022, at 6:49 AM, Benno Overeinder wrote:
Gentle reminder, the poll runs until July 9.
Can you say how the poll will be used? There was pretty strong
push-back after the or
On 6/27/2022 4:31 PM, John Levine wrote:
It appears that Michael StJohns said:
I suggest that reserving "_*" names is redundant as (I *think* - I
didn't go looking for the reference?) strings beginning with an
underscore can only be used in left-most components of a DNS name.
Folks -
It's either time to put a stake through the heart of this DNS vampire
that rises from the grave every 6 months, or to push it for
publication. Given that in 8 years it has yet to gain enough traction
for publication, perhaps we de-adopt the draft back into the caring
hands of its aut
On 6/27/2022 4:05 PM, John Levine wrote:
It appears that Peter Thomassen said:
I am proposing to reserve all top-level underscore labels (_*) for special use.
Why?
While I don't think that reserving underscore names will break anything that is
not already broken, I also don't see what proble
On 6/27/2022 11:29 AM, Ted Lemon wrote:
I think your instinct is correct, Tim. It’s not an optimization to
bypass discussion as part of a call for adoption. By asking us to
consider six drafts at once, and discuss none of them, you create a
strong likelihood of insufficient review.
+1 - the s
In line:
On 5/1/2022 1:41 PM, John Levine wrote:
It appears that Mukund Sivaraman said:
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
By way of this, by removing the names of authors, isn't the copyright
notice attributed to the
On 4/14/2022 5:09 PM, Paul Hoffman wrote:
On Feb 1, 2022, at 12:35 PM, Tim Wicinski wrote:
We were reviewing the Working Group Last Call for this, and we received no
comments. We know there was interest in at least moving this forward, but even
Warren concurred we can't send this to the IESG
On 2/1/2022 3:35 PM, Tim Wicinski wrote:
All
We were reviewing the Working Group Last Call for this, and we
received no comments. We know there was interest in at least moving
this forward, but even Warren concurred we can't send this to the IESG
unless there are folks saying they feel it is
On 11/1/2021 11:58 AM, Eric Orth wrote:
The important part for preserving compatibility with potential future
changes is the "recipients MUST ignore any SvcParams that are present"
part.
I don't understand what would be different if the record sender SHOULD
became a MUST. Recipients wouldn
On 11/1/2021 11:58 AM, Eric Orth wrote:
The important part for preserving compatibility with potential future
changes is the "recipients MUST ignore any SvcParams that are present"
part.
I don't understand what would be different if the record sender SHOULD
became a MUST. Recipients wouldn
Hi EKR -
Your table looks correct and hope.
You may want to take a look at section 5.9 of RFC 6840, as well as
appendix B as there's some implementation guidance with respect to the
setting of the CD bit.
Mike
On 10/6/2021 7:47 PM, Eric Rescorla wrote:
Hi folks,
We've been trying to tak
wrote:
On Sun, Aug 1, 2021 at 6:04 PM Michael StJohns <mailto:m...@nthpermutation.com>> wrote:
Actually, maybe there should be a general document "DNS Squatting
Considered Harmful"?
I think that we (well, mainly ICANN) already have a large amount that
says things
Actually, maybe there should be a general document "DNS Squatting
Considered Harmful"? I personally don't see any real difference
between squatting on "onion" vs squatting on "zz" except that we ended
up with a ex post facto approval of .onion. And that AIRC was a near
thing.
So maybe:
1
d up, and
that mostly doesn't describe the IOT side of things.
Later, Mike
On 1 Jul 2021, at 05:26, Michael StJohns wrote:
Peter et al -
It might be useful to review RFC 4986 -
https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS
Security Trust Anchor Rollover
Peter et al -
It might be useful to review RFC 4986 -
https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to
DNS Security Trust Anchor Rollover - to understand what the problem
requirements were/are before resurrecting this discussion again. If
the requirements have changed,
On 6/18/2021 7:11 PM, Paul Wouters wrote:
Section 6.1.7 confuses me a bit as it defines a numResolvers variable,
and uses that to calculate an acceptable new timing period. To me it
feels that number of resolvers should not matter, as we should stick
to the formal time where all resolvers are eit
On 6/18/2021 6:32 PM, Paul Hoffman wrote:
On Jun 18, 2021, at 2:21 PM, Wes Hardaker wrote:
Peter van Dijk writes:
I propose replacing rfc5011-security-considerations
I keep meaning to republish it with Olafur's suggested reduced title
(since it's really describing just one problem). But it
On 2/3/2021 2:31 PM, Paul Hoffman wrote:
On Jan 29, 2021, at 9:31 AM, Michael StJohns wrote:
I can't support this as Standards track even though it purports to update
standards as it doesn't actually specify an implementable protocol.
Basically, this is dependent upon humans
On 1/29/2021 10:22 AM, Tim Wicinski wrote:
All
After a quick check with the other chairs, we're ready to move this
draft forward.
This starts a Working Group Last Call for draft-ietf-dnsop-nsec-ttl
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-
On 9/23/2020 9:11 PM, Donald Eastlake wrote:
Hi,
Replying on just one point:
On Mon, Sep 21, 2020 at 2:27 PM Michael StJohns wrote:
...
2.2.4 - SHA384 has a hash length of 48 bytes. 12 bytes seems to imply
some sort of left or right truncation. Show stopper! Explain how this
value was
ncluded without WG review. 2.2.4 is the one that I would have
problems with the most.
Mike
On 9/21/2020 2:26 PM, Michael StJohns wrote:
1.4.4 - "has not been modified." -> "has not been modified between
origination and retrieval."
2.2.2 - "MUST be impleme
1.4.4 - "has not been modified." -> "has not been modified between
origination and retrieval."
2.2.2 - "MUST be implemented" -> "SHOULD be implemented. Failure to
implement this scheme without other standardized schemes being specified
may result in a receiver being unable to validate the zon
On 7/23/2020 1:38 PM, Joe Abley wrote:
I do appreciate that STD 13 mentions "master" in some cases as a synonym for "primary";
however, it doesn't mention them in a couple with "slave" and I think this is an example of where
low-numbered RFCs sometimes need to be read in their historical contex
On 6/14/2020 5:53 PM, Paul Wouters wrote:
On Sun, 14 Jun 2020, Michael StJohns wrote:
That said, I'd prefer it if the document selected a few (<=10) codes
from these ranges so that filtering may be built into
various servers and clients to prevent leakage.
Then you would ex
Roy et al -
Is there a document from ICANN taking a position on the assignment of
TLDs based on ISO3166 assignments?
When Jon was doing this he was adamant about following their lead -
rather than having to make political decisions about what was a
country. The main role he had was not the
ovides enough general benefit nor does it provide a standard
and programmatic answer to "what do I do if it doesn't verify", but I'm
no longer adamant it needs to be experimental as it no longer forces a
contract for future digesting models.
Later, Mike
On 3/9/2020 5:24
On 4/30/2020 11:15 AM, Ted Lemon wrote:
On Apr 29, 2020, at 8:01 PM, Michael StJohns <mailto:m...@nthpermutation.com>> wrote:
If you've got an securely insecure (e.g. delegation was to an
insecure zone at some point) CNAME that points into a secure zone, I
would say your resu
On 4/29/2020 5:50 PM, Ted Lemon wrote:
Is there an RFC or draft that talks about what the right thing is to do when an
unsigned CNAME points to a record in a signed zone?
That is, suppose we are doing validation. The CNAME doesn’t validate, because
it’s not signed. When we look up the record t
On 3/11/2020 2:19 PM, Hollenbeck, Scott wrote:
(Sorry, this is a late response to a review request original sent to the dnsop
list on 11 February)
Section 3.4 (DNS for Cloud Resources) includes these sentences:
"Globally unique names do prevent any possibility of collision at the present or in
On 3/9/2020 4:46 PM, Wessels, Duane wrote:
Michael StJohns pointed out (Feb 25) that a verifier that does not
recognise a particular
ZONEMD Scheme and/or Hash Algorithm may be unable to create the
required placeholders,
and therefore unable to perform a verification using any
(Scheme,Algorithm
On 2/27/2020 12:46 PM, Wessels, Duane wrote:
On Feb 24, 2020, at 7:32 PM, Michael StJohns wrote:
An improvement, but still:
Thanks Mike.
1.3 - general - add something like "Specifically, ZONEMD covers the integrity of records that are not otherwise covered by DNSSEC".
Sorr
An improvement, but still:
1.3 - general - add something like "Specifically, ZONEMD covers the
integrity of records that are not otherwise covered by
DNSSEC".
1.3.5 - "zone digest calculation" not simply "zone digest" - this
doesn't require a ZONEMD record.
1.3.2, 1.3.3 and 1.3.4 are mos
On 1/15/2020 8:39 PM, Paul Hoffman wrote:
On Jan 15, 2020, at 5:28 PM, Michael StJohns wrote:
I think its a co-existence issue here. I don't think you should have two
different (calculation-wise) ZONEMD-like RRSets in the same zone for the
reasons you've mentioned.
That makes
On 1/15/2020 1:25 PM, Brian Dickson wrote:
I don't disagree with the notion of a strong differentiator between
ZONEMD and any other digest, either using RRTYPE or with an
underscore-prefix name.
However, there is a Heisenberg problem, which is that any other digest
type needs to be excluded f
Thought I'd forgotten about this? :-)
On 1/8/2020 3:13 PM, John R Levine wrote:
On Wed, 8 Jan 2020, Michael StJohns wrote:
I'm running a private copy of the root zone for my organization. I
(automated) check the SOA every so often, and arrange for a download
of the zone when it cha
On 1/8/2020 4:22 PM, Wessels, Duane wrote:
On Jan 8, 2020, at 12:20 PM, Paul Vixie wrote:
can we please not put the ZONEMD RR at the apex, or else, can we please add an
ALG-ID to its rdata. because some day we're going to ship different kinds of
MD's, one of which is today's full-zone travers
On 1/8/2020 2:07 PM, John R Levine wrote:
Could you give me a b) for each of these please? E.g. How does
ZONEMD make your life better in each of these and what would happen
if you - in a future world - were getting ZONEMD data and validation
failed?
Unless someone else says they find this l
On 1/7/2020 10:05 PM, Brian Dickson wrote:
My $0.02 on the size issue:
I think the onus should be on whoever is publishing a zone with a
ZONEMD to provide guidance on what to do if a failure occurs.
Similarly, publishers should be sensible on whether to include a
ZONEMD based on total size and
On 1/7/2020 6:38 PM, Wessels, Duane wrote:
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
On 1/7/2020 6:01 PM, Wessels, Duane wrote:
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 sa
On 1/7/2020 5:33 PM, Wessels, Duane wrote:
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
On 1/6/2020 9:36 PM, John Levine wrote:
In article <7f298591-09b5-dd7c-0dab-afc60def8...@nthpermutation.com> you write:
OK.� The point is not to self-approve, but to get a few other
non-authors to actually see if they can figure out what you're talking
about here and whether they're ever going t
On 1/6/2020 6:21 PM, Wessels, Duane wrote:
Hello Mike, thanks for the feedback.
Hi Duane -
On Jan 4, 2020, at 5:14 PM, Michael StJohns wrote:
Hi Tim et al -
I read through this back a few versions ago and mostly thought it harmless as
an experimental RFC. I'm not sure that
On 1/6/2020 1:48 PM, John R Levine wrote:
Well, OK, here's a concrete example. I download the COM zone every
day from Verisign, and also a separate file with an MD5 hash of the
main file. Using RFC 2119 language, what do I do if the hash I get
doesn't match their hash? ...
Ok - you've describ
On 1/6/2020 12:13 PM, John Levine wrote:
In article <9952199f-9ea5-2d51-a5d2-6aaf80577...@nthpermutation.com> you write:
If a computer can't figure out what to do with a failed validation
absent human interaction then you might as well say:
"ZONEMD RRs may be safely ignored by all but the geeki
On 1/5/2020 2:00 PM, John Levine wrote:
In article <84650844-1d13-9377-c913-23dcbc76d...@nthpermutation.com> you write:
1) A recommendation for the maximum size of the zone (and for that
matter the maximum churn rate). This is hinted at in the abstract, but
missing from the body of the document.
Hi Tim et al -
I read through this back a few versions ago and mostly thought it
harmless as an experimental RFC. I'm not sure that it's quite ready for
prime time as a Standards track RFC.
Here's what I think is missing:
1) A recommendation for the maximum size of the zone (and for that
m
On 12/3/2019 5:21 PM, Ralf Weber wrote:
Moin!
On 3 Dec 2019, at 3:15, Michael StJohns wrote:
From 2181:
The TC bit should be set in responses only when an RRSet is required
as a part of the response, but could not be included in its
entirety.
The TC bit should not be set merely
On 11/21/2019 1:53 AM, Wes Hardaker wrote:
During the first DNSOP meeting at IETF 106 there was a discussion that
had multiple opinions about what to do with setting the TC bit for EDE
information, which is generally supplemental. During my presentation I
mentioned that an associate of Viktor su
Hi -
I had someone ask me (last night!!) whether or not the "must sign each
RRSet with all of the algorithms in the DNSKEY RRSet" rule applies if
the only key with algorithm A in the RRSet has the revoke bit set. A
question I had never previously considered.
Given that you can't trace trust
On 10/31/2018 2:54 PM, Paul Vixie wrote:
Jim Reid wrote:
On 31 Oct 2018, at 00:27, Mark Andrews wrote:
Bootstrap is still a issue. Over fast TA rolling makes it more of
a issue.
Indeed. And that's the underlying problem that needs to be fixed IMO
- for instance when/if there's an emerge
Generally, CRLs work reasonably well for revoking intermediate CAs and
leaf certificates, not so well for dealing with trust anchors. CRLs
work by the parent signing the revocation (and by being able to re-issue
new certificates). Root certs/trust anchors by definition do not have
parents.
On 9/6/2018 3:08 PM, Steve Crocker wrote:
How do you prevent compromise of the central service?
The "Dealer" is only doing confidential processing during the key
generation phase. Once that's done, you can do a wipe. The
subsequent signature operations are all distributed. The combine
o
On 7/10/2018 12:34 PM, Paul Hoffman wrote:
On 10 Jul 2018, at 11:35, Michael StJohns wrote:
And as you may have guessed I object to the publication of this
document on the basis of quality for all the reasons previously
stated. This version of the document is actually in worse shape than
n the changes now, and as well as during the
session on Wednesday.
Tim
On Mon, Jul 9, 2018 at 12:05 PM, Michael StJohns
mailto:m...@nthpermutation.com>> wrote:
Tim/Suzanne -
Please cancel the request for publication until you complete the
WGLC for this document.
The la
e.
Later, Mike
On 7/6/2018 9:08 PM, Michael StJohns wrote:
On 7/6/2018 8:13 PM, Tim Wicinski wrote:
Tim Wicinski has requested publication of
draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed
Standard on behalf of the DNSOP working group.
Please verify the d
On 7/6/2018 8:13 PM, Tim Wicinski wrote:
Tim Wicinski has requested publication of
draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed Standard on
behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-sec
On 4/18/2018 5:07 PM, Suzanne Woolf wrote:
Second, does this work add significantly to the complexity of the DNS protocol,
or the work of implementers and operators?
A slight respin of this bullet: Does this work change the way the
infrastructure of the protocol works, or is this work target
Sorry its taken me so long to get back to this.
On 3/31/2018 7:09 PM, Tony Finch wrote:
There are a few pertinent differences between trust anchor witnesses and
the undeployed RFC 5011 many-keys setup:
* in RFC 5011 each key is completely trusted, whereas no witness is
trusted; compromise o
provided a system
that was designed to be relatively bit-rot resistant (on a system basis)
for a design life in excess of 40 years given reasonable attention to
administration. No system related to the DNS can be 100% bit-rot
resistant for all clients given the one-way nature of the DNS dat
Hi -
Joe Abley introduced draft-jabley-dnsop-bootstrap-validator [jabbootval]
at the DNSOP session this past week. I was the only (one of the few?)
person who suggested that this was a bad idea. Later that week, we ran
into each other in the bar and chatted for not long enough to sync, but
l
something like that Mike
On Sun, Mar 25, 2018 at 11:04 PM, Michael StJohns
mailto:m...@nthpermutation.com>> wrote:
Apologies for dumping this here, but I figured if anyone had a
clue they'd probably be on this list. Is anyone familiar with
mopo-io.com.cn <http://mopo-
Apologies for dumping this here, but I figured if anyone had a clue
they'd probably be on this list. Is anyone familiar with
mopo-io.com.cn? Is this a legitimate email (or company)? If not, its
one of the better phishing emails I've seen.
Thanks - Mike
Forwarded Message
*pounds head on table* I'm really not sure how things get worse each
time but they appear to.
Please, please get rid of activeRefreshOffset, clockskewDriftMargin and
retryDriftMargin. Replace this with a single paragraph noting that
the maximum time (assuming no retransmissions) a node has
On 12/20/2017 1:15 PM, Wes Hardaker wrote:
Michael StJohns writes:
1) Drift happens per query.
Agreed. I'll go double check that I didn't imply that, or better: make
sure I state that in the document.
Take it out of any formula. It has little impact outside of the
addHoldDow
I didn't think this could get worse. I was wrong.
I can't support any version of this document for publication. In the
same way that activeRefreshOffset is a nonsensical value so to are
driftSafetyMargin and timingSafetyMargin.
1) Drift happens per query.
2) Any drift that happens related
nt. For the last four columns, those values
represent the number of times a client exceeded the calculated safe
interval (and divide by the total number of clients to get a
percentage...).
Later, Mike
On 12/15/2017 6:55 PM, Wes Hardaker wrote:
Michael StJohns writes:
Below is a java progr
Below is a java program I wrote to model this stuff. In the table, SF2
represents the number of clients that blew past twice the safety factor
(for aR+aHD+aR), SF1 represents the number of clients that blew past the
single safety factor. OF is the number of clients using the
activeRefreshOffs
On 12/12/2017 4:03 PM, Wes Hardaker wrote:
Michael StJohns writes:
A "perfect" system will behave the way you've described - but adding a
safety factor while ignoring the phase shift brought on by retransmits
within the addHoldDown interval will not characterize the actual
syst
On 12/12/2017 12:24 PM, Wes Hardaker wrote:
Michael StJohns writes:
2) T + activeRefresh is the time at which the server sees the last
query from the last resolver just starting their trust anchor
installation.
3) T + activeRefresh + addHoldDownTime is the time at which the server
sees the
On 12/11/2017 8:03 PM, Wes Hardaker wrote:
Michael StJohns writes:
Hi Mike,
Thanks for explaining your thinking because I think, after reading it:
we're actually in agreement but using different terms for where to put
in the slop you're worried about.
Specifically:
A perfectly
To try this out, let’s use a ttl of 28 hours and an expiration of 7 days to
get an active refresh as below.
Take an activeRefresh of 14 hours (giving a fast retry of 2.8 hours and an
addHoldDown time of 30 days (720 hour). That gives you an
activeRefreshOffset of 6 hours. A perfect resolver will
On 12/7/2017 7:53 PM, Wes Hardaker wrote:
Michael StJohns writes:
Much improved - but still some disconnects (all review is de novo):
That's Mike. All good comments. I've attached responses and actions
(or inactions) below and will push a new version shortly as well.
Wes Hardak
On 11/29/2017 5:29 PM, Wes Hardaker wrote:
internet-dra...@ietf.org writes:
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Domain Name System
Operations WG of the IETF.
FYI, this contains the restructuring talked about during I
On 11/20/2017 11:26 AM, Wes Hardaker wrote:
Michael StJohns writes:
1 something.
I think that the consensus is clearly something like that. Are you
(MSJ) interested in supplying a suggested final equation for it?
Ok - after thinking about it, it turns out to be fairly simple.
1
I’m running the math right now to see what works. Give me a few days.
Mike
On Mon, Nov 20, 2017 at 11:26 Wes Hardaker wrote:
> Michael StJohns writes:
>
> > 1 something.
>
> I think that the consensus is clearly something like that. Are you
> (MSJ) interested in supply
1 something. I also believe it should scale as to the size of the
subscription base in some way. Basically, this should answer the question
of “ given a set of subscribers of size N, a per request failure rate of f,
a retry time of R, how long do you have to wait until P% of the subscribers
have
On 10/31/2017 4:51 PM, Paul Hoffman wrote:
And once again we see the folly of the words "implementation choice"
when trying to come up with a coherent DNS.
The full quote makes the situation murkier: it is a combination of
implementation choice plus configuration options. Some folks on this
l
On 10/31/2017 5:39 AM, Moritz Muller wrote:
Hi,
Together with my colleagues I have been stumbling upon a, for me, unclear case
when validating trust anchors.
Assuming that a resolver has enabled DNSSEC validation and has the root keys
configured.
Additionally, it has configured manually a tru
1 - 100 of 141 matches
Mail list logo
