Speaking Personally, these all three seem reasonable.
I can easily see a reason for the second error code (local root),
especially as a debugging/test case.
Also personally, I feel like the DNS community needs a quality error code
similar to HTTP 418.
But I will shut up and show myself out.
tim
op/wg-materials/blob/main/dnsop-ietf120/dnsop-ietf120-minutes.txt
DNSOP WG
Vancouver, BC, Canada
Session 1
Date: Monday, July 22, 2024
Time: 15:30-17:00 local
Chairs: Benno Overeinder, Suzanne Woolf, Tim Wicinski
https://datatracker.ietf.org/doc/chatlog-120-dnsop-202407221530/
Only discussion during th
Roy
That is on Thursday Agenda. Sorry for the mixuyp
On Mon, Jul 22, 2024 at 3:47 PM Roy Arends wrote:
> I saw this on the agenda for this afternoon.
>
> The proposed solution against zone-walking is to exclude names from an
> nsec chain.
>
> Example, say "B" needs to kept private from zone-wa
Tim Wicinski has requested publication of draft-ietf-dnsop-rfc7958bis-03 as
Informational on behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/
___
DNSOP ma
On Thu, Jul 11, 2024 at 3:36 PM John R Levine wrote:
> On Thu, 11 Jul 2024, Tim Wicinski wrote:
> >> A) Should verification records have a tag at the front of the data to
> >> identify the record type? There's plenty of prior art for this, e.g.,
> >> the 63 t
Duane
Thanks for these. I'm going to capture these for the authors (at least one
is currently on holiday).
On Tue, Jul 9, 2024 at 5:55 PM Wessels, Duane wrote:
> I read through draft-ietf-dnsop-domain-verification-techniques-05 and have
> a few minor comments / suggestions.
>
>
>
> > this may
I'm going to try to answer a few of these John, as acting Document
Shepherd, herder of author kittens.
On Tue, Jul 9, 2024 at 5:23 PM John Levine wrote:
> It appears that Tim Wicinski said:
> >This is one of those DNSOP documents that may not be relevant to those who
> &
All
I wanted to call your attention to the most recent update on this
document. The authors have worked through a number of open issues
primarily around editorial clarity and reorganization of the
recommendations. I want to personally thank the authors for working
through these issues, and my co
Geoff,
On Thu, Jul 4, 2024 at 8:58 PM Geoff Huston wrote:
>
> I think you appear to be getting "requestor" and "responder" confused in
> your proposed text. Did you mean to say the following?
>
>
Arrgh - Guilty and thank you for that.
UDP responders should compose response response packets wit
Paul
On Thu, Jul 4, 2024 at 6:41 PM Paul Vixie
wrote:
> On Thursday, July 4, 2024 7:05:22 AM PDT Tim Wicinski wrote:
>
> > On Tue, Jul 2, 2024 at 9:26 PM David Farmer wrote:
>
> > > 2. Also, maybe R5 should have text similar to R3 with "...the minimum
>
&
All
A reminder Call for Agenda Items for the IETF 120 in Vancouver, Canada.
Draft Submission Deadline is Monday 8 July 2024.
Please email the chairs with your requests.
*Or* drop us a pull request
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf120
look for dnsop-ietf120-agenda
t; Internet Systems Consortium
>
>
> On 02. 07. 24 21:49, Tim Wicinski wrote:
> >
> > (please note I'm sending this to DNSOP and V6OPS)
> >
> > All
> >
> > The authors have addressed the comments made during the IESG process and
> > feedback from
questors should limit the requestor's maximum UDP payload size to
use the RECOMMENDED size of 1400 bytes, but a smaller limit MAY be used."
tim
> Thanks
>
> On Tue, Jul 2, 2024 at 2:52 PM Tim Wicinski wrote:
>
>>
>> (please note I'm sending this to DNSOP an
Agree with Paul. There is also "Load Balancing DNS Services" which is more
of a L4 network situation, which I have witnessed (and still do) in
enterprise networks.
On Wed, Jul 3, 2024 at 12:38 PM Paul Hoffman wrote:
> On Jul 3, 2024, at 09:32, Peter Thomassen wrote:
> >
> >
> >
> > On 7/3/24
ighly confident" they will a new version before the
document cut off on Monday. The chairs are highly confident as well.
Thanks for the great reviews.
tim
On Wed, Jun 19, 2024 at 12:32 PM Tim Wicinski wrote:
>
> All
>
> The authors have updated the document based on some
(no hats)
I concur with the concurs of the topic distinction.
Thanks Davey and Shumon for reading something to read later!
tim
On Wed, Jul 3, 2024 at 11:30 AM Shumon Huque wrote:
> Yes, I concur with this distinction Ben, and also that both these topics
> deserve discussion.
>
> Shumon.
>
>
convinced the authors will have updated versions by
Monday, and we will spend the weeks before IETF addressing any comments.
Thanks for your patience.
tim
On Sat, Apr 27, 2024 at 8:38 PM Tim Wicinski wrote:
> All
>
> These were discussed at the last IETF and the chairs felt
(please note I'm sending this to DNSOP and V6OPS)
All
The authors have addressed the comments made during the IESG process and
feedback from DNS implementers, and have published version 18.
The links for the diff are mentioned below. I will point out the
additional introduction paragraph added
Hi
This is a reminder that the WGLC for draft-ietf-dnsop-rfc7958bis still has
one week remaining. We've received two reviews and comments, but we
would like to receive some more from the working group.
Thanks
tim
On Wed, Jun 19, 2024 at 12:32 PM Tim Wicinski wrote:
>
> All
>
Tim Wicinski has requested publication of draft-ietf-dnsop-rfc8109bis-05 as
Best Current Practice on behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
___
On Wed, Jun 19, 2024 at 2:49 PM Paul Vixie wrote:
> This document makes the argument that because of how things work at the
> moment, we should limit our aspirations.
>
> I completely disagree.
>
I agree with Paul. We deserve nice things - we may not be there today, but
we should strive to get
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&url2=draft-ietf-dnsop-rfc7958bis-02&difftype=--html
This star
All
We chairs wanted to let the working group know that the authors will be
publishing new versions with the recommendations that there is agreement
on.
They are hoping to get all this done before the document submission
deadline (or maybe that was the chair's optimism).
tim
On Tue, May 14, 202
`To follow up on this discussion, I've talked with Paul and I'm OK with
leaving the last paragraph of section 3.3 in place. Joe Abley has been the
only other outspoken one on this.
I have the feeling/consensus/vibes that the latest version makes the text
clearer. We will discuss this with Warren
All
This working group has been wrangling with our document on
avoid-fragmentation, and the various opinions of how DNS should handle
this, based on years and years of implementation experience.
I noticed a few days ago that the IPv6 folks have offered up their opinions
on this subject. I urge D
Thanks Paul for the data (and the thoughts!). I also missed this and
have some reading to do.
tim
On Mon, Jun 17, 2024 at 7:05 PM Geoff Huston wrote:
> Thanks for the pointer!
>
> g
>
>
> > On 18 Jun 2024, at 7:17 AM, Paul Hoffman wrote:
> >
> > On Jun 17, 2024, at 13:33, Geoff Huston wro
On Mon, Jun 17, 2024 at 12:19 PM Joe Abley wrote:
> On 17 Jun 2024, at 17:54, Tim Wicinski wrote:
>
> Oh that's a very good point, and does make that assumption. "will be
> valuable if root-servers.net is DNSSEC signed" does not make that
> assumption.
>
>
ot make that
assumption.
tim
> On 17 Jun 2024, at 17:40, Tim Wicinski wrote:
>
>
> Paul is correct on this - we would like a few more comments on the
> clarification changes to RFC8109-bis.
> Also, Willem offered some suggested text to the last paragraph of 3.3
> re
-documents-2020-11-05-en
> >
> > Please let us know if you have any issues with the changed text in the
> new version.
> >
> > --Paul Hoffman
> >
> >
> > On Jun 5, 2024, at 08:25, Tim Wicinski wrote:
> >>
> >> All
> >>
> >
FC 8499 (Obsoleted by RFC 9499)
thanks
tim
> --Paul Hoffman
>
>
> On Jun 5, 2024, at 08:25, Tim Wicinski wrote:
> >
> > All
> >
> > The chairs are requesting some final comments on
> draft-ietf-dnsop-rfc8109bis. As you might recall, this document has
All
The chairs are requesting some final comments on
draft-ietf-dnsop-rfc8109bis. As you might recall, this document has already
been through WGLC and had consensus to advance, but our AD reviewed it and
raised some additional questions. (Warren Kumari, “AD Review of
draft-ietf-dnsop-rfc8109bis,”
Tim Wicinski has requested publication of draft-ietf-dnsop-zoneversion-06 as
Informational on behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/
___
DNSOP ma
discussion.
tim
(just a contributor)
On Thu, May 9, 2024 at 10:29 PM Tim Wicinski wrote:
> I wrote a note to Peter and his co-author on this discussion and
> we(chairs) feel that Paul W is correct in saying _signal is too generic.
>
> We should not overload any underscore label for multi
I wrote a note to Peter and his co-author on this discussion and we(chairs)
feel that Paul W is correct in saying _signal is too generic.
We should not overload any underscore label for multiple purposes. If
another type of operator signalling appears, a new label can be acquired.
Being specific
All
These were discussed at the last IETF and the chairs felt there was
consensus to request adoption.
This starts a Call for Adoption for:
draft-hardaker-dnsop-rfc8624-bis
draft-hardaker-dnsop-must-not-sha1
draft-hardaker-dnsop-must-not-ecc-gost
The drafts are available here:
h
All
Thanks for two successful sessions of DNSOP and thanks to Paul Hoffman for
his note taking !
I've uploaded the minutes into the datatracker:
https://datatracker.ietf.org/meeting/119/materials/minutes-119-dnsop-01
I made sure the links to the chat logs for the DNSOP sessions are in the
minut
Tim Wicinski has requested publication of
draft-ietf-dnsop-dnssec-bootstrapping-07 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-dnssec-bootstra
Not wearing any hats, really
I want to thank Wes and Warren for putting this together and I think this
is a good way to build on the good work that RFC8624 produced.
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi
This working group last call wrapped up last week, but between OARC and a
multi-vendor CVE I allowed myself to get distracted.
I'll do the shepherd writeup later this week
thanks
tim
On Sat, Jan 20, 2024 at 6:23 PM Tim Wicinski wrote:
>
> All
>
> Peter has integrated
Again thanks to mr Hoffman for minutes, here they are and uploaded in
the datatracker and our git repo
Thank you one and all for having great productive conversations!
tim
DNSOP WG
Interim meeting 2024-01-30 1700 UTC
Chairs: Benno Overeinder, Suzanne Woolf, Tim Wicinski
Minutes taken by Paul
John
On Tue, Jan 30, 2024 at 11:29 AM John Dickinson wrote:
> On 30/01/2024 16:21, Joe Abley wrote:
> > On 30 Jan 2024, at 15:57, Roy Arends wrote:
>
> >>> If an authority server is capable of loading a DELEG RRSet and
> generating referral responses accordingly, it's surely also possible of
(my vibes only)
On Tue, Jan 30, 2024 at 11:21 AM Joe Abley wrote:
>
>
> I think specifying rules about which to prefer is important. But I also
> think it's worth thinking more pessimistically around what kinds of
> failures will result when people get that wrong. We have already seen this
> wit
Wes
On Mon, Jan 29, 2024 at 6:45 PM Wes Hardaker wrote:
> IESG Secretary writes:
>
> > The Domain Name System Operations (dnsop) WG will hold a virtual
> > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam
> > (17:00 to 18:00 UTC).
>
> I'm sadly very day-job conflicted with t
someone
feels we missed something, please speak up.
thanks
tim
On Sat, Jan 20, 2024 at 6:23 PM Tim Wicinski wrote:
>
> All
>
> Peter has integrated feedback from the first working group last call, and
> we'd like to do a followup last call. The diff with the curre
Tim Wicinski has requested publication of draft-ietf-dnsop-rfc8109bis-02 as
Best Current Practice on behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
___
:54 PM 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:
> https://datatracker.ietf.org/doc/draft-ietf
All
Peter has integrated feedback from the first working group last call, and
we'd like to do a followup last call. The diff with the current version is
here:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-dnssec-bootstrapping-05&url2=draft-ietf-dnsop-dnssec-bootstrapping-07&difftype
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 push
we missed something, please speak up.
thanks
tim
On Mon, Jan 8, 2024 at 8:54 PM 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 d
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 Curre
, 2023 at 3:14 AM Tim Wicinski wrote:
>
> The WGLC closes next week, Saturday, December 24.
>
>
> This should say *Sunday* December 24.
>
> thanks
>
> Tim
> (currently double checking some appointments)
>
>>
___
Sat, Dec 16, 2023 at 9:55 AM Tim Wicinski wrote:
> Dear WG,
>
> The working group was asked to adopt draft-bash-rfc7958bis “DNSSEC Trust
> Anchor Publication for the Root Zone” as a working group document, and the
> call went out on October 12 this year. So far we've seen one su
The WGLC closes next week, Saturday, December 24.
This should say *Sunday* December 24.
thanks
Tim
(currently double checking some appointments)
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Dear WG,
After the premature start of the first Working Group Last Call (WGLC) for
draft-ietf-dnsop-rfc8109bis by the chairs, a second WGLC was initiated on
October 10, 2023.
The document has remained relatively stable over the past two years, except
for the addition of missing sections in the la
Dear WG,
The working group was asked to adopt draft-bash-rfc7958bis “DNSSEC Trust
Anchor Publication for the Root Zone” as a working group document, and the
call went out on October 12 this year. So far we've seen one support email
on the list, and during the IETF 117 DNSOP WG session the chairs f
All
Apologies for taking a bit longer than we thought, but we wanted to send
out our list of chair's actions taken from the last meeting.
If anyone thinks we missed something please let us know.
thanks
tim
---
## IETF118 Chairs Actions
### Actions
* draft-ietf-dnsop-dnssec-bootstrapping
DNSOP
DNSSD has placed a call for adoption for Ray Bellis' document on Multi
Qtypes. Current version is here.
https://www.ietf.org/archive/id/draft-bellis-dnsext-multi-qtypes-08.html
The DNSOP chairs would like the DNSOP working group to comment on this call
for adoption.
We are aware that not e
review to make sure if you are quoted that you are
quoted correctly, etc.
The chairs are working up a list of actions to take from the meeting that
we'll send out this week.
Tim
along with Benno and Suzanne
DNSOP WG
IETF 118, Prague
Chairs: Benno Overeinder, Suzanne Woolf, Tim Wicinski
Mi
ing 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
> > >
> > > Cur
Martine
First thanks for the presentation this morning. Second, I am your DNS
Directorate reviewer for draft-ietf-core-dns-over-coap,
and I realize I owe your latest versions a review. Geoff/Jim - I wonder if
we should have a second pair of eyes on this document?
While I am not one of the DNS
ication,
> Resulting in potentially unwanted censorship...
>
> Gianpaolo
>
> Inviato da Outlook per Android <https://aka.ms/AAb9ysg>
>
>
> C2 General
> --
> *Da:* Ben Schwartz
> *Inviato:* Giovedì, Novembre 9, 2023 5:14:26 PM
>
On Thu, Nov 9, 2023 at 10:02 AM Ben Schwartz wrote:
> Note that "mailto" URIs can pre-populate subject and body contents, so
> information about the specific blocked item and other metadata could be
> populated automatically. This seems sufficient for enterprise use cases
> like allowing employe
Chairs
* Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl)
* Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com)
* Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com)
### IESG Overlord
* Warren Kumari [war...@kumari.net](war...@kumari.net)
### Document Status
* [Github](htt
Hi
This is another relatively small document that is updating RFC7958,
and needs to be updated prior to the next KSK rollover.
This starts a Call for Adoption for draft-bash-rfc7958bis
"DNSSEC Trust Anchor Publication for the Root Zone"
The draft is available here:
https://datatracker.ietf.org/d
draft-ietf-dnsop-qdcount-is-one into the datatracker.
The chairs hope Mr. Bellis is rested from his holiday to address this task.
thanks
tim
On Thu, Sep 28, 2023 at 12:59 PM Tim Wicinski wrote:
>
> We want to thank Joe and Ray for getting this republished with the notes
> from the
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 p
All
I know this was a bit longer than a week, but we wanted to receive some
confirmations from folks with questions on implementations. We've received
that, and the chairs feel the consensus is to move forward.
Thanks
tim
On Tue, Sep 19, 2023 at 2:27 PM Tim Wicinski wrote:
> (fo
Tim Wicinski has requested publication of
draft-ietf-dnsop-avoid-fragmentation-15 as Best Current Practice on behalf of
the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragment
Paul,
Thanks for getting an update done!. I started reviewing it (as now I
want to double check), but we should should get this out back on the top of
the stack.
tim
On Thu, Oct 5, 2023 at 6:16 PM Paul Hoffman wrote:
> On Sep 14, 2023, at 18:46, Tim Wicinski wrote:
>
> > We
Tim Wicinski has requested publication of draft-ietf-dnsop-zoneversion-04 as
Informational on behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/
___
DNSOP ma
We want to thank Joe and Ray for getting this republished with the notes
from the previous meeting.
Thanks Ted and Eric for their comments today, we will remember them.
I will say that this chair likes the appendix, to remind me what I
have glossed over, as the authors have already corrected me on
Thanks Joe for pulling this together.
tim
On Thu, Sep 28, 2023 at 10:57 AM Ted Lemon wrote:
> Thanks for the update. I think this does the job. I could do without the
> appendix, but I understand the urge to fully document. :)
>
> On Thu, Sep 28, 2023 at 9:40 AM Joe Abley wrote:
>
>> Hi all,
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 73
(forgive my missing subject previously)
All
After pulling this back (Thanks Peter again), we went back to the authors
and
In the case of the DF bit, the wording is changed from
"UDP responders are RECOMMENDED" to "UDP responders MAY"
They also added some additional text in the security sectio
Followup One Week Working Group Last Call for
draft-ietf-dnsop-avoid-fragmentation
All
After pulling this back (Thanks Peter again), we went back to the authors
and
In the case of the DF bit, the wording is changed from
"UDP responders are RECOMMENDED" to "UDP responders MAY"
They also added s
On Sun, Sep 17, 2023 at 5:01 AM Joe Abley wrote:
> Hi Murray!
>
> Op 17 sep. 2023 om 08:07 heeft Murray Kucherawy via Datatracker <
> nore...@ietf.org> het volgende geschreven:
>
> > I thought the IESG (though maybe not this particular one) had previously
> > discouraged publishing "living docume
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".
Peter
On Fri, Aug 18, 2023 at 11:33 AM Peter van Dijk
wrote:
> Hello Tim,
>
> On Wed, 2023-08-16 at 15:45 -0700, Tim Wicinski via Datatracker wrote:
> > Tim Wicinski has requested publication of
> draft-ietf-dnsop-avoid-fragmentation-14 as Best Current Practice on behalf
>
call to put more eyes onto a document.
tim
On Wed, Sep 13, 2023 at 5:30 PM Geoff Huston wrote:
>
>
> > 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,
> >
>
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
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:
https://datatracker.ietf.org/doc/draft-ietf-dn
All,
Thanks for another productive session of DNSOP. Paul's minutes have been
uploaded. If you made comments at the microphone, please confirm everything
is accurate.
https://datatracker.ietf.org/doc/minutes-117-dnsop/
https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-ietf117/dnsop-
Tim Wicinski has requested publication of
draft-ietf-dnsop-avoid-fragmentation-14 as Best Current Practice on behalf of
the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragment
Duane/Evan/Mukund/All,
What do feel is the consensus on lowering the value to 1 second ?
>From the previous suggested text:
Resolvers MUST cache resolution failures for at least 1 second.
The initial duration SHOULD be configurable by the operator. A
longer cache duration for resolut
Peter
On Mon, Jul 17, 2023 at 3:37 AM Peter van Dijk
wrote:
> On Wed, 2023-07-05 at 18:51 -0400, Tim Wicinski wrote:
>
> All
>
> The authors of draft-ietf-dnsop-avoid-fragmentation worked with different
> implementers to expand upon the index of Known Implementations, and wha
by the operator.
thanks
tim
> DW
>
>
>
> > On Jul 23, 2023, at 9:00 PM, Tim Wicinski wrote:
> >
> >
> >
> > All,
> >
> > We had a discussion this morning during the hackathon about a value with
> > the document caching-resolution-failur
All,
We had a discussion this morning during the hackathon about a value with
the document caching-resolution-failures. The current text in 3.2 says:
Resolvers MUST cache resolution failures for at least 5 seconds. The
value of 5 seconds is chosen as a reasonable amount of time that an
Presenters,
DNSOP is less than 24 hours away and we have one set of slides.
Please submit your slides here:
https://datatracker.ietf.org/meeting/117/session/dnsop
or to the chairs.
The Chairs slides will be uploaded shortly
tim
___
DNSOP mailing list
ith different owners.
>> > First-to-register does not guarantee that the correct ownership could
>> > be determined by creation time (i.e. it's a race condition without a
>> > stronger mechanism.)
>>
>> Explicit disavowal should be able to solve this too,
Tim Wicinski has requested publication of
draft-ietf-dnsop-caching-resolution-failures-05 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-caching-resolution-fai
All
Shivan, Shumon and Paul have incorporated feedback from the WG as well as
several area reviews, and more.
It's a much better document because of that, and we thank everyone.
The chairs want to give the WG a 7-10 days to review the changes and
confirm there are no issues
thanks
tim
On Mon,
ort for it.
Thanks
tim
On Mon, May 29, 2023 at 6:58 PM Tim Wicinski wrote:
>
> All,
>
> The chairs want to thank everyone for the feedback on this document
> recently. We've been in discussions with Warren and the authors about this
> document, and we have some questions we&#x
All
The authors of draft-ietf-dnsop-avoid-fragmentation worked with different
implementers to expand upon the index of Known Implementations, and what
they implement specifically.
The chairs would like to have a one week follow up Working Group Last Call
comment period. We are looking for substan
Erik
I placed your excellent comments into the author's issue tracker, then we
decided to split them up into separate issues.
Take a look to confirm. If anything is wrong, it's one me
tim
APEX domains, and hostnames vs domains
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verificati
email thread as something that
can be addressed.
Authors should fill free to submit to the ISE. We will alert them as well
tim
On Fri, Jun 23, 2023 at 4:18 PM Tim Wicinski wrote:
>
> All
>
> Draft-dulaunoy-dnsop-passive-dns-cof was originally submitted back in
> 2014, and has h
Momoka
Thanks for making DNSOP aware of this. We encourage anyone with comments
on the document adoption to reach out.
Everything I've heard and read on this work (wearing no hats) is that this
is good work and should be adopted.
thanks
tim
On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto wro
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 G
All
Draft-dulaunoy-dnsop-passive-dns-cof was originally submitted back in 2014,
and has had 10 revisions since then.
https://datatracker.ietf.org/doc/draft-dulaunoy-dnsop-passive-dns-cof/
Note that the format is now fixed, and there are several implementations.
We had asked DNSOP (in the poll w
All
The Chairs have been talking about this for awhile, and we want to try an
experiment and to start holding open 'office hours.' This would be a time
when anyone is welcome to drop in and chat with the chairs about mentoring,
roadblocks on drafts, cross-area concerns, process questions, etc. The
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
1 - 100 of 680 matches
Mail list logo
