Re: [DNSOP] Artart early review of draft-ietf-dnsop-domain-verification-techniques-01

es/ > > On Mon, 3 Apr 2023 at 00:38, Barry Leiba via Datatracker > wrote: >> >> Reviewer: Barry Leiba >> Review result: Ready with Nits >> >> This is short and reasonably sweet, easily digested. I have a few minor >> comments that I think will hel

Re: [DNSOP] Artart last call review of draft-ietf-dnsop-caching-resolution-failures-06

Thanks, Duane! Barry On Wed, Aug 9, 2023 at 5:14 PM Wessels, Duane wrote: > > Thanks Barry for the good feedback. I've updated our source document with > the changes you've suggested. > > DW > > On 8/9/23, 1:10 PM, "Barry Leiba via Datatracke

[DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

I am handling this document as responsible AD, as Warren is a co-author and so must recuse himself. I’m not sure how I missed the publication request, but miss it I did, and thanks to Warren for pinging me. Thanks for a very well-written and clear document. I have only some minor editorial comme

Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

> > I wonder if it makes sense to be more explicit here that one isn’t > > meant to keep using expired data forever, but is expected to keep > > trying to refresh it. So, maybe?: > > > > NEW > > If the data is unable to be > > authoritatively refreshed when the TTL expires, the record

Re: [DNSOP] AD review of draft-ietf-dnsop-serve-stale-07

Puneet, that sounds perfect. Thanks for reconsidering this. Barry On Wed, Sep 18, 2019 at 8:14 AM Puneet Sood wrote: > > On Sat, Sep 14, 2019 at 8:46 AM Barry Leiba wrote: > > > > > > I wonder if it makes sense to be more explicit here that one isn’t > > > &

[DNSOP] AD review of draft-ietf-dnsop-7706bis-07

I am handling this document as responsible AD because Warren, who would otherwise do it, is irresponsible an author of the document. I have only two comments, below, that are total nits, and I will request last call as soon as I send this message. Nice work, as always, Warren and Paul. Barry —

Re: [DNSOP] AD review of draft-ietf-dnsop-7706bis-07

No reason to do it now; it can wait. b On Fri, Feb 14, 2020 at 12:57 AM Warren Kumari wrote: > > > On Fri, Feb 14, 2020 at 7:42 AM Barry Leiba > wrote: > >> I am handling this document as responsible AD because Warren, who would >> otherwise do it, is irr

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

Thanks for the review, Ines. Barry On Fri, Feb 28, 2020 at 5:02 AM Ines Robles via Datatracker < nore...@ietf.org> wrote: > Reviewer: Ines Robles > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF docu

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-7706bis-07

Thanks, Ace, and post the update whenever you’re ready. Barry On Fri, Feb 28, 2020 at 10:18 AM Warren Kumari wrote: > On Fri, Feb 28, 2020 at 8:02 AM Ines Robles via Datatracker > wrote: > > > > Reviewer: Ines Robles > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer

[DNSOP] AD review of draft-ietf-dnsop-dns-zone-digest-08

I am serving as responsible AD for this document, because Warren is an author, and so is recused. Here’s my AD review. Most comments are minor, but I’d like to resolve the ones in Sections 2 and 3.1 before going to last call, so I’ll set the substate to “AD Followup”. — Section 1 — Zone file

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt

I just put it into IESG Evaluation a couple of hours ago. The recent changes were to address the SecDir review, which you can see here: https://mailarchive.ietf.org/arch/msg/secdir/RYS_YRmcHvwEauT-6UhvtqSJ9-8/ Barry On Mon, Sep 21, 2020 at 3:06 PM Michael StJohns wrote: > > Adding IESG - I didn

[DNSOP] Ongoing discussion of DoH, DoT, and related issues

most likely in the ART Area but with significant crossover expected and desired from Ops, Sec, Int, and probably the rest of the solar system IETF community. Barry Leiba, ART AD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-onion-tld-00: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https

Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

to do more of this, we should reserve one specific TLD for it (or use one we already have), and have the uses migrate to that TLD. Barry > On 21/08/15 19:37, Barry Leiba wrote: >> -- >> COMMENT: >> -

Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

> valid point, however with respect to 6761 the onion namespace > substantially predates the existence of 6761 or the consensus documented > there so I don't think the what if scenario is particularly helpful Indeed, and Stephen pointed that out to me privately as well. That was a mistake in my r

[DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-qname-minimisation-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-edns-tcp-keepalive-04: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-edns-tcp-keepalive-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

[DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-5966bis-05: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-5966bis-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-edns-tcp-keepalive-04: (with COMMENT)

Thanks for the quick response, Sara, and for addressing my comments. Barry On Wednesday, January 6, 2016, Sara Dickinson wrote: > > > On 6 Jan 2016, at 07:57, Barry Leiba > wrote: > > > > Barry Leiba has entered the following ballot position for > > draft-ietf-d

Re: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-5966bis-05: (with COMMENT)

>> In the light of edns-tcp-keepalive, do we really want to say this? It's >> true, but it sounds like a recommendation. Maybe we might say something >> like, "Clients often close the TCP connection after sending a single >> request, but see [draft-ietf-dnsop-edns-tcp-keepalive]." ? > > Well, thi

Re: [DNSOP] [regext] Any interest in draft-latour-dnsoperator-to-rrr-protocol ?

>> I think it would fall under REGEXT once it's up? The REGEXT charter >> has a section about DNS Operator. >> >>> The working group will also identify the requirements for a >>> registration protocol where a third-party DNS provider is involved. >>> These requirements will be documented in an Info

[DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-edns-chain-query-06: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-edns-chain-query-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

[DNSOP] Artart last call review of draft-ietf-dnsop-alt-tld-22

Reviewer: Barry Leiba Review result: Ready Thanks for a clear, concise, and, if I may say, valuable document. I couldn't even find any typos. I have two very minor comments, both of which can be ignored if you prefer: 1. In Section 4, you use "somename.alt" -- was that chosen ov

[DNSOP] Artart early review of draft-ietf-dnsop-domain-verification-techniques-01

Reviewer: Barry Leiba Review result: Ready with Nits This is short and reasonably sweet, easily digested. I have a few minor comments that I think will help make the document slightly clearer, and I hope you'll consider them: — Section 3.1 — I think this is generally understandable, but

[DNSOP] Artart last call review of draft-ietf-dnsop-caching-resolution-failures-06

Reviewer: Barry Leiba Review result: Ready with Nits Thanks for a well-written document. I found the background information in Section 1.1 to be particularly interesting. Just a couple of very small editorial points there: operating system vendor was providing non-root trust anchors to the

[DNSOP] Artart last call review of draft-ietf-dnsop-avoid-fragmentation-15

Reviewer: Barry Leiba Review result: Ready with Issues Thanks for an easy-to-read and useful document. I have just a few minor issues to raise here: — Section 1 — TCP avoids fragmentation using its Maximum Segment Size (MSS) parameter, but each transmitted segment is header-size aware

[DNSOP] Artart telechat review of draft-ietf-dnsop-avoid-fragmentation-16

Reviewer: Barry Leiba Review result: Ready with Nits Thanks for addressing most comments from my earlier review. One remains, and I didn’t see an email response about it, so I don’t know whether there was a reason not to make a change or if it just got overlooked: — Section 7.2 — If a UDP

[DNSOP] Artart early review of draft-ietf-dnsop-domain-verification-techniques-05

Reviewer: Barry Leiba Review result: Ready This has a significantly expanded scope from the -01 version that I reviewed a while ago. I think it's solid, well written, and ready for last call. ___ DNSOP mailing list -- dnsop@ietf.org To unsubs

[DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-rfc2845bis-07: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-rfc2845bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-no-response-issue-20: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-no-response-issue-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

[DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-server-cookies-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-algorithm-update-07: (with COMMENT)

Barry Leiba has entered the following ballot position for draft-ietf-dnsop-algorithm-update-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[DNSOP] Artart last call review of draft-ietf-dnsop-must-not-sha1-03

Reviewer: Barry Leiba Review result: Ready with Nits By themselves (without “RSA”), SHA-1, SHA-256 and other “SHA-nnn” designations are hash (or digest) algorithms, not encryption algorithms, and we should probably be more careful about what we call them. In this document it doesn’t matter much

[DNSOP] Artart last call review of draft-ietf-dnsop-must-not-ecc-gost-03

Reviewer: Barry Leiba Review result: Ready Ready to go, with no further comment. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Artart last call review of draft-ietf-dnsop-rfc8624-bis-06

Reviewer: Barry Leiba Review result: Ready Fine and useful; excellent. Just the nittiest nit of nittiness in Section 1.2: By the time a DNSSEC cryptographic algorithm is made mandatory-to- implement …and… newly introduced algorithms will become mandatory-to-implement in the future