I'm glad to see this thread on the list.
First, a plug for this draft which is an attempt to lay a foundation for
the discussion. There's at least one outstanding edit for it, it's not
complete and is intended to be changed via discussions like this. The
document hasn't been considered for WG ad
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Domain Name System (DNS) Cookies'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send subst
Tim & other fellow dnsop folks,
At 2015-11-28 08:22:07 -0500
Tim Wicinski wrote:
> There was a lot of positive support for this draft in Yokohama, so this
> is considered
>
> This starts a Call for Adoption for draft-ogud-dnsop-maintain-ds
>
> The draft is available here:
> https://datatracke
Hi Mark,
> On Nov 29, 2015, at 6:55 PM, Mark Andrews wrote:
>
>
>
> Some feedback with respect to installed trust anchors is needed.
>
> Whether this is the correct solution I'm not sure. It requires
> updating all resolvers in the resolution path to both cache and
> relay tags.
I'm not su
On Mon, Nov 30, 2015 at 05:29:53PM +, Wessels, Duane wrote:
> As I've said a number of times before, the edns-key-tag proposal is modelled
> after RFC 6975, which does the same thing for algorithms. If it works for
> algorithms why wouldn't it work for key tags?
Does it work? Has anyone depl
At Sun, 29 Nov 2015 15:16:28 +0100,
Stephane Bortzmeyer wrote:
> > > That was exactly my point, and in that sense I'd say "SHOULD
> > > delete" is redundant (and possibly imposes unnecessary
> > > restrictions on implementations).
> >
> > Yes, I agree. The current description is a bit too impleme
Dear Wesley Hardaker, Ólafur Guðmundsson, Suresh Krishnaswamy:
An IPR disclosure that pertains to your Internet-Draft entitled "DNSSEC
Roadblock Avoidance" (draft-ietf-dnsop-dnssec-roadblock-avoidance) was
submitted to the IETF Secretariat on and has been posted on the "IETF Page of
Intellectual
>IMHO, I believe that there can be a way to attach resolution semantics to
>top-level names and implement this in the API level. IOW, for DNS "above
>the DNS" in the software stack. This is just a belief, not a certainty.
Well, sure, that's how .onion and .local work now. But there's no
general
>> In a well designed system, names are only used to name things.
>
>I disagree, I think.
>
>In a "well designed" system, a name is meaningful to different parties
>differently. We can use it as a person's easy to remember name, or we
>can use it to express a relationship, or we can use it to ensur
I'm still reading through this draft, but a few things jumped out at me right
away. Some of them are typos, others merely "style" issues, one is a
jargon/definitional issue, and then one observation that goes somewhat deeper.
TYPOS: Intro: "not a necessarily" should be simply "not necessarily".
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 Working Group
of the IETF.
Title : A Common Operational Problem in DNS Servers - Failure
To Respond.
Author : M. And
All,
I think this is a nice approach for gaining confidence in a rollover of
a key that acts as a trust anchor. It can even be used to detect
validators that have missed the rollover.
I would however be cautious with using the information as an event
trigger. The draft says
The goal of these
12 matches
Mail list logo
