All
The authors have updated the document based on some early reviews. Since
this is an update from the original RFC7958, I urge folks to take a look at
the diff from the original:
https://author-tools.ietf.org/iddiff?url1=rfc7958=draft-ietf-dnsop-rfc7958bis-02=--html
This starts a Working
Hi Petr,
On Mar 26, 2024, at 12:14, Petr Špaček wrote:
>> Personally I think we do need people to read a little bit beyond the title
>> if they are going to extract useful meaning from the document. If we accept
>> that to be a reasonable goal then perhaps having a title that seems slightly
On 19. 03. 24 7:15, Joe Abley wrote:
Hi Chris,
Thanks for the review!
On 19 Mar 2024, at 03:28, Chris Box wrote:
It is a little cart-before-horse in having the reasoning occur after the
conclusion. But I can see the benefit in having a very clear statement up front
in the document. Some
Hi Chris,
Thanks for the review!
On 19 Mar 2024, at 03:28, Chris Box wrote:
> It is a little cart-before-horse in having the reasoning occur after the
> conclusion. But I can see the benefit in having a very clear statement up
> front in the document. Some people only read the beginning.
DNSOP,
I've reviewed draft-ietf-dnsop-qdcount-is-one-02. I find it generally very
clear. It is a little cart-before-horse in having the reasoning occur after
the conclusion. But I can see the benefit in having a very clear statement
up front in the document. Some people only read the beginning.
I’ve reviewed qdcount-is-one-02 and find it to be ready for publication as an
RFC.
DW
> On Mar 5, 2024, at 6:51 AM, Suzanne Woolf wrote:
>
> Hi,
>
> We're leaving this open a few more days to allow for any other comments. We'd
> like to submit it for publication before IETF 119.
>
>
>
Hi,
We're leaving this open a few more days to allow for any other comments. We'd
like to submit it for publication before IETF 119.
Thanks,
Suzanne
For the chairs
On Feb 15, 2024, at 10:57 AM, Suzanne Woolf wrote:
Hi,
The qdcount draft is brief and straightforward, and there have been no
On 20 Feb 2024, at 11:55, jab...@strandkip.nl wrote:
> That is some good, arcane DNS knowledge right there, Niall, I like it!
8-)
> [...]
> Perhaps it's worth making it even more clear that this is just a provision
> for AXFR responses by specifying the QTYPE? Something like:
>
> DNS Zone
On 20 Feb 2024, at 12:38, Niall O'Reilly wrote:
> I think it would help, for completeness, and the better
> to support the inexperienced reader of the DNS scriptures,
> to include mention of RFC5936 (AXFR) in the "brief summary
> of the guidance provided in the existing DNS specification"
>
On 15 Feb 2024, at 15:57, Suzanne Woolf wrote:
> The qdcount draft is brief and straightforward
and very welcome.
I think it would help, for completeness, and the better
to support the inexperienced reader of the DNS scriptures,
to include mention of RFC5936 (AXFR) in the "brief summary
of the
Hi,
The qdcount draft is brief and straightforward, and there have been no new
changes proposed or issues introduced since the -01 version was posted. We
think there’s likely consensus to advance it for publication.
This note starts a Working Group Last Call for
All
The Working Group Last Call has completed, and thank you all for your
comments. We consider the document to have consensus to move forward.
The authors (Paul) will upload the latest version with the changes
suggested, and we will move this forward.
thanks
tim
On Mon, Jan 8, 2024 at 8:54
Thanks Peter and Paul
I'll review the revised I-D but we were thinking of going another (perhaps
shorter) follow up working group last call
tim
On Fri, Jan 19, 2024 at 8:59 AM Peter Thomassen wrote:
> For the record, Paul and I sorted these out off-list (for real, this
> time!), and I'll
For the record, Paul and I sorted these out off-list (for real, this time!),
and I'll push a new revision of the draft shortly.
~Peter
On 11/20/23 16:49, Peter Thomassen wrote:
Hi Paul, (off-list)
To keep the ball rolling, may I nudge you for your opinion on the below? :)
Thank you very
All
This is a followup on our Working Group Last Call
for draft-ietf-dnsop-rfc8109bis is ongoing until Monday January 22, 2024.
There has been support for publication, but we are always looking for more
feedback.
The comments raised appear to have been resolved by the authors. If someone
feels
I support publication. The remainder feel like nits which would get
resolved in editor queue.
I discussed the priming issue with Paul H privately and I think his
response covered my concerns. Basically, if you run hyperlocal root,
it subsumes the functionality of the cache priming activity, but
Let me try that again with proper indentation.
> On 9 Jan 2024, at 01:54, Tim Wicinski wrote:
>
> All
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the draft is available here:
>
> On 9 Jan 2024, at 01:54, Tim Wicinski wrote:
>
> All
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the draft is available here:
>
On Mon, 8 Jan 2024, Tim Wicinski wrote:
Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
From my previous comments (still unaddressed, were my comments rejected?)
there are 13 root servers.
I would really like to see this changed. We keep trying to tell
All
This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
The Current Intended Status of this document is: Best
Hi Paul, (off-list)
To keep the ball rolling, may I nudge you for your opinion on the below? :)
Thank you very much for your input,
Peter
On 11/13/23 22:30, Peter Thomassen wrote:
Hi Paul,
Thanks for your thoughts. I'd like to address your points below and would very
much appreciate your
Hi all,
Thank you for everyone's responses.
The authors have created a pull request on the draft's repo with the changes
suggested in this thread, which might get amended based on additional feedback.
Changes:
- Add Glauca registrar implementation [based on Q's input]
- Editorial changes to
Hi John,
On 11/14/23 20:07, John Levine wrote:
The chairs announced today that the below WGLC meant to say that some reactions
in support of this draft are needed for the document to move
forward. (In contrast to only asking for objections.)
I think the document is ready EXCEPT that we
It appears that Peter Thomassen said:
>Dear DNSOP,
>
>(This is mainly for those who did not attend today's DNSOP session in Prague.)
>
>The chairs announced today that the below WGLC meant to say that some
>reactions in support of this draft are needed for the document to move
>forward. (In
Hi Paul,
Thanks for your thoughts. I'd like to address your points below and would very
much appreciate your follow-up response.
On 11/11/23 12:55, Paul Wouters wrote:
I have read the document and I am supportive of the idea, but I find the
document not ready. Some issues I have with the
ation and normative text and work
> with Peter on that.
>
> I will let Peter and Nils respond to your technical comments. I do think
> all can be addressed,
> but I am also an optimist.
>
> Thanks again.
>
> tim
>
>
> On Sat, Nov 11, 2023 at 6:56 AM Paul W
organization and normative text and work with
Peter on that.
I will let Peter and Nils respond to your technical comments. I do think
all can be addressed,
but I am also an optimist.
Thanks again.
tim
On Sat, Nov 11, 2023 at 6:56 AM Paul Wouters wrote:
>
> > Subject: Re: [DNSOP] Working G
Subject: Re: [DNSOP] Working Group Last Call for
draft-ietf-dnsop-dnssec-bootstrapping
On 9/19/23 21:48, Tim Wicinski wrote:
>
> This starts a Working Group Last Call for
draft-ietf-dnsop-dnssec-bootstrapping
>
> Current versions of the draft
I support advancing this document.
Brian Dickson (speaking only for myself)
On Fri, Nov 10, 2023 at 4:46 AM Peter Thomassen wrote:
> Dear DNSOP,
>
> (This is mainly for those who did not attend today's DNSOP session in
> Prague.)
>
> The chairs announced today that the below WGLC meant to say
> On Nov 10, 2023, at 4:46 AM, Peter Thomassen wrote:
>
> (This is mainly for those who did not attend today's DNSOP session in Prague.)
>
> The chairs announced today that the below WGLC meant to say that some
> reactions in support of this draft are needed for the document to move
>
Hi,
I support the dnssec bootstrapping method as proposed
draft-ietf-dnsop-dnssec-bootstrapping. .CA is looking at an implementation.
Jacques
CLASSIFICATION:CONFIDENTIAL
___
DNSOP mailing list
DNSOP@ietf.org
Hi Peter, hi all,
Am 10.11.2023 um 13:46 schrieb Peter Thomassen:
Dear DNSOP,
(This is mainly for those who did not attend today's DNSOP session in
Prague.)
The chairs announced today that the below WGLC meant to say that some
reactions in support of this draft are needed for the document
Dear DNSOP,
(This is mainly for those who did not attend today's DNSOP session in Prague.)
The chairs announced today that the below WGLC meant to say that some reactions
in support of this draft are needed for the document to move forward. (In
contrast to only asking for objections.)
So, if
Hi all,
Just a quick note (as requested by Peter Thomassen) to say that we (
https://glauca.digital) have implemented
draft-ietf-dnsop-dnssec-bootstrapping for our registrar’s CDS bootstrapping.
Thanks,
Q
--
Any statements contained in this email are personal to the
Hi all,
For others following along: Upon Tim's suggestion towards the end of this WGLC,
I had sent notes to a handful of ICANN folks who are involved with DNSSEC, but
who may not be subscribed this list. I forwarded the WGLC message to them on
Sep 29 and extended Tim's invitation to offer
Hi All
We had so much fun the first timeActually this chair wishes to thank Mr
Abley and Mr Huston for catching our error so quickly, and we apologize for
any and all inconvenience.
I did go back and looked at the history AND also reread the document.
I do wish to point out that there are 4
On 9/19/23 21:48, Tim Wicinski wrote:
This Document will update 7344 and 8078 if approved.
The Document updates brings up something I wanted to raise.
Peter and I chatted about some simple nits (remove references from the
abstract),
but I wasn't sure if the sections updating older documents
This starts a Working Group Last Call for
draft-ietf-dnsop-dnssec-bootstrapping
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
The Current Intended Status of this document is: Standards Track
This Document will update
All
We chairs heard back from the authors and we're pulling this working group
last call.
I want to share some background - Paul and I talked at 117 and he said the
document is ready, and I trust Paul
implicitly in these matters. Then when the dnsdir review came back as it
was I was like "OK".
Hi Benno,
On 9/14/23 10:14, Benno Overeinder wrote:
As Tim mentioned, the chairs paused WGLC or WG Call for Adoptions in August and
are now starting the chairs action points in September. Your
draft-ietf-dnsop-dnssec-bootstrapping document is scheduled immediately after
this WGLC. We will
Hi Nils and Peter,
Thanks for your email regarding the process.
On 14/09/2023 09:53, Peter Thomassen wrote:
Unlike draft-ietf-dnsop-rfc8109bis which has been adopted only in June
2023, draft-ietf-dnsop-dnssec-bootstrapping has been sitting there, with
several implementations and without any
Missing reference:
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/vHltEr8mlxsy2nyscqcCF2ZGz8U/
On 9/14/23 09:53, Peter Thomassen wrote:
Hi Tim,
On 9/13/23 23:05, Tim Wicinski wrote:
We Chairs are back and catching up, and want to get things moving again.
This starts a Working Group Last
Hi Tim,
On 9/13/23 23:05, Tim Wicinski wrote:
We Chairs are back and catching up, and want to get things moving again.
This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"
Current versions of the draft is available here:
> On 14 Sep 2023, at 6:33 am, Tim Wicinski wrote:
>
>
> Geoff
>
> We had a DNS directorate review done
> https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc8109bis-00-dnsdir-early-ma-2023-08-29/
> And perhaps I was basing my vibes off of the review plus the authors. That is
> on me.
Geoff
We had a DNS directorate review done
https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc8109bis-00-dnsdir-early-ma-2023-08-29/
And perhaps I was basing my vibes off of the review plus the authors. That
is on me. But also, we chairs sometimes see the need to use the working
group last
> On 14 Sep 2023, at 6:25 am, Tim Wicinski wrote:
>
>
>
> On Wed, Sep 13, 2023 at 5:20 PM Joe Abley wrote:
> Hi Tim,
>
> Op 13 sep. 2023 om 23:06 heeft Tim Wicinski het volgende
> geschreven:
>
>>
>> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
>>
> On 14 Sep 2023, at 6:20 am, Joe Abley wrote:
>
> Hi Tim,
>
> Op 13 sep. 2023 om 23:06 heeft Tim Wicinski het volgende
> geschreven:
>
>>
>> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
>> "Initializing a DNS Resolver with Priming Queries"
>>
>> Current
On Wed, Sep 13, 2023 at 5:20 PM Joe Abley wrote:
> Hi Tim,
>
> Op 13 sep. 2023 om 23:06 heeft Tim Wicinski het
> volgende geschreven:
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the
Hi Tim,
Op 13 sep. 2023 om 23:06 heeft Tim Wicinski het volgende
geschreven:
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the draft is available here:
>
Hi All
We Chairs are back and catching up, and want to get things moving again.
This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
"Initializing a DNS Resolver with Priming Queries"
Current versions of the draft is available here:
Dear WG,
This ends the WGLC for draft-ietf-dnsop-dns-error-reporting.
The last call has been extended a bit longer than initially planned, but
valuable feedback has been received from the WG on the the draft. Thank
you very much.
The authors published a -05 revision a week ago that
On Mon, Jul 10, 2023 at 10:27:45PM +0100, Roy Arends wrote:
> > Right, but surely the monitoring agent can decide whether to solicit
> > such a prefix label or not. That is whether an "_er" prefix label is
> > signalled is a *local matter* betweent the authoritative server
> > signalling the
Hi Viktor,
Again, thank you for your detailed, in-depth and insightful response. My
comments are inline, and I’ve removed the parts in agreement.
> On 10 Jul 2023, at 17:58, Viktor Dukhovni wrote:
>
> On Wed, Jul 05, 2023 at 12:17:34PM +0100, Roy Arends wrote:
>
>>> The proposed qname
Chairs
Subject: Re: [DNSOP] Working Group Last call for
draft-ietf-dnsop-dns-error-reporting
!---|
This Message Is From an External Sender
|---!
Ben,
Thanks
e authoritative server
SHOULD respond with TC bit set to force a re-query over TCP.
Hope this suffices.
Warmly,
Roy
> --Ben SchwartzFrom: DNSOP on behalf of Benno
> Overeinder
> Sent: Thursday, June 8, 2023 5:59 AM
> To: DNSOP Working Group
> Cc: DNSOP
On Wed, Jul 05, 2023 at 12:17:34PM +0100, Roy Arends wrote:
> > I would prefer to require resolvers to be more tolerant of unexpected
> > options, and would have servers report the channel without explicit
> > solicitation.
>
> That is indeed the plan. I shall make that explicit in the new
Hi Duane,
On Wed, Jul 5, 2023 at 18:32, Wessels, Duane
<[dwessels=40verisign@dmarc.ietf.org](mailto:On Wed, Jul 5, 2023 at 18:32,
Wessels, Duane < wrote:
> On Jun 30, 2023, at 2:32 PM, Joe Abley wrote:
>
>> I wonder whether another subsection of section 2 would be useful to discuss
>>
> On Jun 30, 2023, at 2:32 PM, Joe Abley wrote:
>
>
>
> I have read -04. i like it. I think it's useful and sensible and it should be
> published. Whether this particular rev is ready for publication I would say
> depends on whether the authors disagree with all the pedantic nonsense that
All
The Working Group Last Call has completed and the chairs thank everyone for
their comments.
It appears that the authors have addressed all issues, and the document is
ready to advance.
tim
On Wed, Jun 21, 2023 at 11:00 AM Tim Wicinski wrote:
> All
>
> This starts a Working Group Last
Viktor, thanks for your feedback. Comments inline.
> On 26 Jun 2023, at 22:13, Viktor Dukhovni wrote:
>
> On Thu, Jun 08, 2023 at 11:59:59AM +0200, Benno Overeinder wrote:
>
>> This starts a two week Working Group Last Call process, and ends on:
>> June 22nd, 2023.
>
> I hope my feedback is
On Jun 21, 2023, at 11:00, Tim Wicinski wrote:
> This starts a Working Group Last Call for
> draft-ietf-dnsop-caching-resolution-failures
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/
>
> The Current
On 26/06/2023 16:47, Peter van Dijk via Datatracker via dnsdir wrote:
The document has not seen a lot of WG discussion; I hope
this means people have read it and generally agree.
Yes, I've read through the document now again and I generally agree with it.
(But I'm afraid I can't think about
On Thu, Jun 08, 2023 at 11:59:59AM +0200, Benno Overeinder wrote:
> This starts a two week Working Group Last Call process, and ends on:
> June 22nd, 2023.
I hope my feedback is not too late. There are a few important elements
of the draft that could use some changes.
On Tue, Jun 20, 2023 at
_
From: DNSOP on behalf of Benno Overeinder
Sent: Thursday, June 8, 2023 5:59 AM
To: DNSOP Working Group
Cc: DNSOP Chairs
Subject: [DNSOP] Working Group Last call for
draft-ietf-dnsop-dns-error-reporting
!---|
This Messa
All
This starts a Working Group Last Call for
draft-ietf-dnsop-caching-resolution-failures
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/
The Current Intended Status of this document is: Proposed
Standard/Standards
On Jun 20, 2023, at 16:40, Dick Franks wrote:
>
>
> WGLC is supposed to be a review, nit-picking and clarification process.
A “review” can have results requiring major changes. But your use here seems to
imply “only small changes”. This is incorrect.
Documents in WGLC could be found to
> On 20 Jun 2023, at 23:35, Dick Franks wrote:
>
> On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote:
>> 8
>
>>
>> The change was from -03 to -04 and discussed in the WG IIRC. The specific
>> sentence your refer to was a lingering oversight in the changes from -03 to
>> -04. I have
On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote:
>8
>
> The change was from -03 to -04 and discussed in the WG IIRC. The specific
> sentence your refer to was a lingering oversight in the changes from -03 to
> -04. I have consulted many developers on this, and so far I had no push back.
>
> >
Correction
Deleting that one sentence changes the meaning of the proposal from
explicitly querying the authoritative server for the appropriate
report channel to a dependence on authoritatives attaching an
-(unsolicited) EDNS0 report channel option to each and every query.
> On 20 Jun 2023, at 21:39, Dick Franks wrote:
>
> On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote:
>> 8
>
>>> On 20 Jun 2023, at 12:14, Willem Toorop wrote:
>> 8
>
>>> I have one nit.
>>>
>>> In the Example in section 4.2., a request still "includes an empty ENDS0
>>> report channel".
On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote:
>8
> > On 20 Jun 2023, at 12:14, Willem Toorop wrote:
>8
> > I have one nit.
> >
> > In the Example in section 4.2., a request still "includes an empty ENDS0
> > report channel". The third paragraph of that same section states something
> >
On Tue, 20 Jun 2023 at 12:14, Willem Toorop wrote:
>8
> In the Example in section 4.2., a request still "includes an empty ENDS0
> report channel". The third paragraph of that same section states
> something similar: "As support for DNS error reporting was indicated by
> a empty EDNS0 report
Thank Dick!
> On 16 Jun 2023, at 18:33, Dick Franks wrote:
>
> All
>
> I have reviewed the document which appears to be almost ready for
> submission to IESG.
>
>
> Subsection 6.1.1 uses QNAME to refer to two different entities.
> The opening sentence needs to say nothing more than that the
Hoi Willem,
> On 20 Jun 2023, at 12:14, Willem Toorop wrote:
>
> Op 08-06-2023 om 11:59 schreef Benno Overeinder:
>> Dear DNSOP WG,
>>
>> The authors and the chairs feel this document has reached the stage where
>> it's ready for Working Group Last Call.
>>
>> This starts a Working Group
Op 08-06-2023 om 11:59 schreef Benno Overeinder:
Dear DNSOP WG,
The authors and the chairs feel this document has reached the stage
where it's ready for Working Group Last Call.
This starts a Working Group Last Call for:
draft-ietf-dnsop-dns-error-reporting.
Dear all,
I find this is a
All
I have reviewed the document which appears to be almost ready for
submission to IESG.
Subsection 6.1.1 uses QNAME to refer to two different entities.
The opening sentence needs to say nothing more than that the report
query is a concatenation of the listed items.
The conflicting usage is
All,
The DNSOP WG chairs would like to see more feedback from the working group.
We understand that there have been thorough reviews of previous drafts
and implementation feedback has been provided to the authors, but even
if there are no comments, we still appreciate supporting statements
Hi Peter,
Thanks for the feedbacks. I agree that the idea of shortening the TTL based
on all TTLs of the chains may be too intrusive and not respect the
willingness of the authoritative server - which also needs to be taken into
account. One other reason we removed such recommendation was also
Thanks Benno!
I have received a fix from Dick Franks. I forgot to update this field from:
Value Name Status Reference
- ---
TBD Agent-Domain Standard [this document]
To:
Value Description Status
Dear DNSOP WG,
The authors and the chairs feel this document has reached the stage
where it's ready for Working Group Last Call.
This starts a Working Group Last Call for:
draft-ietf-dnsop-dns-error-reporting.
Current versions of the draft is available here:
Hi Daniel,
On 5/18/23 02:26, Daniel Migault wrote:
On 5/17/23 22:01, Daniel Migault wrote:
> I agree but as far as can see the cap of the TTL with a revalidation
will only resync the resolver and the zone more often than could be expected
otherwise but does not result in the cached
Hi Peter,
Thanks for the response. I think I need to understand better how
revalidation is performed.
Yours,
Daniel
On Wed, May 17, 2023 at 4:26 PM Peter Thomassen wrote:
> Hi Daniel,
>
> On 5/17/23 22:01, Daniel Migault wrote:
> > I agree but as far as can see the cap of the TTL with a
Hi Peter,
Thanks you very much for these comments. I will look carefully how to
implement carefully these comments in our new version.
Yours,
Daniel
On Tue, May 16, 2023 at 1:08 PM Peter Thomassen wrote:
>
>
> On 5/12/23 23:09, Viktor Dukhovni wrote:
> > Repost of my belated comments in the
Hi Daniel,
On 5/17/23 22:01, Daniel Migault wrote:
I agree but as far as can see the cap of the TTL with a revalidation will not
only resync the resolver and the zone more often than could be expected
otherwise but does not result in the cached RRsets differing from those
provided by the
Hi Viktor,
Thanks for the feedbacks. Please see my comment/responses below.
Yours,
Daniel
On Fri, May 12, 2023 at 5:10 PM Viktor Dukhovni
wrote:
> On Wed, Oct 19, 2022 at 03:21:27PM -0400, Tim Wicinski wrote:
>
> > This starts a Working Group Last Call for
> >
On 5/12/23 23:09, Viktor Dukhovni wrote:
Repost of my belated comments in the thread, apologies about not doing
it right the first time...
Inspired by Viktor's comments, I spent some time to give the document a
thorough review.
I'd like to support Viktor's comments on the dependent RRset
On Wed, Oct 19, 2022 at 03:21:27PM -0400, Tim Wicinski wrote:
> This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-validator-requirements
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/
>
>
Dear WG, authors,
Summarising the feedback on the mailing list and follow-up steps for the
authors.
The feedback of Sara has been incorporated in
draft-ietf-dnsop-rfc8499bis-06.
The feedback of Peter consists of two items:
1) clarification zone origin to parent zone origin (in the section
Dear WG,
Thank you for your feedback, also from Peter Thomassen in another email
thread about the glue definition.
Herewith I close the WGLC.
Best,
-- Benno
On 20/02/2023 15:37, Sara Dickinson wrote:
Hi,
LGTM.
I’ve opened a small PR to just update the DoQ references now there is an
I think Paul conveyed the authors' opinions here pretty well. Just wanted
to respond to the token generation bit:
On Fri, 17 Feb 2023 at 08:22, Paul Wouters wrote:
> John Levine wrote:
>
> > While I think it would be good to publish some best practices in this
> area,
> > this draft still seems
Dear DNSOP WG,
Following lengthy discussion, including the latest consultation with the.
Working Group on bailiwick and in-domain/sibling name servers terminology, the
authors and chairs believe this document is ready for Working Group Last Call.
As described earlier,
Hi,
LGTM.
I’ve opened a small PR to just update the DoQ references now there is an RFC:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-rfc8499bis/pull/12
Regards
Sara.
> On 17 Feb 2023, at 15:51, Benno Overeinder wrote:
>
> Dear DNSOP WG,
>
> Following the latest consultation with the
It appears that Brian Dickson said:
>DC templates generally are of the key/value pair structure, with the
>"value" typically being specific to the customer, such as a validation
>string.
Oh, OK, there's a concrete reason to use fixed names and put the token
in the body.
R's,
John
On Fri, Feb 17, 2023 at 4:06 PM tjw ietf wrote:
> John
>
> Paul is right. As an operator one thing I always obsess on in is the data
> in my zones. Why is it there , should it be, etc. Another example you may
> understand is “who created this incorrect DMARC record?”
>
> I’ve given them much
It appears that Paul Wouters said:
>But also, the pain is not felt at the people who dictate how to use
>their DNS validation scheme. It is with the DNS administrators finding
>a bunch of unrecognisable DNS records and not knowing what the hell
>they are for and whether they can or should be
John
Paul is right. As an operator one thing I always obsess on in is the data in my
zones. Why is it there , should it be, etc. Another example you may understand
is “who created this incorrect DMARC record?”
I’ve given them much much feedback. I am eager for others to sound off.
And
On Fri, 17 Feb 2023, John R Levine wrote:
Surely we know people who run services that use DNS validation. How about
talking to some of them and finding out what kind of user errors they run
into?
The insinuation here is that we didn't talk to them. One of the authors
is at salesforce, who
On Fri, 17 Feb 2023, John Levine wrote:
That makes no sense. Why is it harder to copy a string to the name field
in a cruddy web GUI than to the data field? It's copy and paste either way.
For one, if the zone data presented to you is like a sorted zone file.
Second, because LHS entries
It appears that Paul Wouters said:
>> _a1b2c3.example.com IN ... "whatever"
>> _crudco.example.com IN ... "a1b2c3"
>
>Adding cryptogrpahically strong/long strings in the prefix seems
>unwieldly and prone to problems - especially if the user has to put
>these in via a webgui of mediocre quality.
John Levine wrote:
While I think it would be good to publish some best practices in this area,
this draft still seems scattered and makes some assertions that seem to me
to be somewhere between unsupported and mistaken.
I think we agree that the goal is there are two parties, call them
owner
1 - 100 of 670 matches
Mail list logo
