[DNSOP] IETF 120 Call for Agenda Items DNSOP WG

2024-06-13 Thread Benno Overeinder

Dear WG,

This is a Call for Agenda Items for the IETF 120 in Vancouver, Canada.

DNSOP has requested two 1.5-hour sessions for IETF 120 and we expect to 
have ample time to discuss the various concepts.  The schedule of these 
sessions will be confirmed when the preliminary IETF 120 agenda is 
published next week on 21 June.


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-requests.md.


Please Note: Draft Submission Deadline is Monday 8 July 2024.

See https://datatracker.ietf.org/meeting/important-dates/:
2024-07-08	Monday	Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D 
Submission Tool https://datatracker.ietf.org/submit/.


Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org


[DNSOP] Re: draft-ietf-dnsop-avoid-fragmentation-17.txt - implementer notes

2024-06-06 Thread Benno Overeinder

Hi all,

Speaking as one of the DNS implementers and as part of providing 
feedback on the current draft revision, we have reformulated 
recommendation R2.  It expresses the intention not to fragment UDP 
packets and points out that different operating systems have different 
ways of achieving this.


The current concern of open-source software DNS developers is with Linux 
that the IP_MTU_DISCOVER is not well documented, it has changed over 
time, one has to look into the kernel code to see what is really going 
on, and it is fragile.


New text for R2:

-

R2.  UDP responders should configure their systems to prevent 
fragmentation of UDP packets when sending replies, provided it can be 
done safely. The mechanisms to achieve this vary across different 
operating systems.


For BSD-like operating systems, the IP "Don't Fragment flag (DF) bit" 
[RFC0791] can be used to prevent fragmentation. In contrast, Linux 
systems do not expose a direct API for this purpose and require the use 
of Path MTU socket options (IP_MTU_DISCOVER) to manage fragmentation 
settings. However, it is important to note that enabling IPv4 Path MTU 
Discovery for UDP in current Linux versions is considered harmful and 
dangerous. For more details, refer to Appendix C.


-


On 06/05/2024 15:59, Petr Špaček wrote:

Hello dnsop,

Warren asked implementers to provide feedback on the current text, so 
I'm doing just that.


I'm not an apt copywriter but hopefully following notes will provide 
material for other people to formulate commentary to supplement the 
recommendations.







Cheers,

-- Benno

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org


[DNSOP] updated agenda for DNSOP WG session on Friday, 22 March 2024

2024-03-21 Thread Benno Overeinder

Dear all,

We have added two /time permitting/ presentations to the DNSOP WG agenda 
for Friday 15:00-16:30 AEST/05:00-06:30 UTC.


For the latest DNSOP agenda, see 
https://datatracker.ietf.org/doc/agenda-119-dnsop/.


Best,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] draft agenda IETF 119 DNSOP published

2024-03-04 Thread Benno Overeinder

All,

We are pleased to announce that the draft agenda for the IETF 119 DNSOP 
sessions has been published.  The sessions are scheduled as follows:


- Monday, March 18, 2024, from 15:30 to 17:00 AEST (05:30-07:00 UTC)
- Friday, March 22, 2024, from 15:00 to 16:30 AEST (05:00-06:30 UTC)

You can view the draft agenda on the datatracker at the following link: 
https://datatracker.ietf.org/doc/agenda-119-dnsop/.



Best,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

2024-03-04 Thread Benno Overeinder



 Forwarded Message 
Subject: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt
Date: Mon, 04 Mar 2024 13:12:26 -0800
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org

Internet-Draft draft-toorop-dnsop-ranking-dns-data-00.txt is now available.

   Title:   Ranking Domain Name System data
   Authors: Paul Hoffman
Shumon Huque
Willem Toorop
   Name:draft-toorop-dnsop-ranking-dns-data-00.txt
   Pages:   4
   Dates:   2024-03-04

Abstract:

   This document extends the list ranking the trustworthiness of domain
   name system (DNS) data (see Section 5.4.1 of [RFC2181]).  The list is
   extended with entries for root server names and addresses built-in
   resolvers, and provided via a root hints file with the lowest
   trustworthiness, as wel as an entry for data which is verifiable
   DNSSEC secure with the highest trustworthiness.  This document
   furthermore assigns ranked values to the positions of the list for
   easier reference and comparison of trustworthiness of DNS data.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-toorop-dnsop-ranking-dns-data/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-toorop-dnsop-ranking-dns-data-00

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 119 Call for Agenda Items DNSOP WG

2024-02-26 Thread Benno Overeinder

Dear WG,

Just a friendly reminder to submit your request for agenda time for the 
upcoming DNSOP WG meeting at IETF 119.  For instructions on requesting a 
time slot during one of the sessions, please refer to the email below.


The DNSOP WG has two sessions scheduled as follows:
- Monday, March 18th, from 15:30 to 17:00 AEST (5:30-7:00 UTC)
- Friday, March 22nd, from 15:00 to 16:30 AEST (5:00-6:30 UTC)

The deadline for draft submissions is next Monday, March 4th, 2024.


Best regards,

Suzanne
Tim
Benno


On 09/02/2024 15:38, Benno Overeinder wrote:

Dear WG,

This is a Call for Agenda Items for the IETF 119 in Brisbane, Australia.

DNSOP has requested two sessions for the IETF 119 so that we have 
sufficient time to discuss individual drafts.  The allocation of two 
sessions is yet to be confirmed and the preliminary IETF119 agenda will 
be published next week, 16 February.


Please email the chairs  with your requests. *Or* 
drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf119 
look for dnsop-ietf119-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 3 March 2024.

See https://datatracker.ietf.org/meeting/important-dates/:
2024-03-04    Monday    Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D 
Submission Tool https://datatracker.ietf.org/submit/.


Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 119 Call for Agenda Items DNSOP WG

2024-02-09 Thread Benno Overeinder

Dear WG,

This is a Call for Agenda Items for the IETF 119 in Brisbane, Australia.

DNSOP has requested two sessions for the IETF 119 so that we have 
sufficient time to discuss individual drafts.  The allocation of two 
sessions is yet to be confirmed and the preliminary IETF119 agenda will 
be published next week, 16 February.


Please email the chairs  with your requests. 
*Or* drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf119 
look for dnsop-ietf119-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 3 March 2024.

See https://datatracker.ietf.org/meeting/important-dates/:
2024-03-04	Monday	Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D 
Submission Tool https://datatracker.ietf.org/submit/.


Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] New mailing list: DNS Delegation

2024-02-09 Thread Benno Overeinder

Hi Ólafur,

On 08/02/2024 16:48, Ólafur Guðmundsson wrote:

Quick questions
why a new list and what is that lists standing in the IETF?
Is this  precursor for a BOF and possible new working group ?


For now, the mailing list is a non-WG list on a specific topic.  If 
there is a new WG after the BoF, discussions on DELEG will continue on 
that WG mailing list (given the name of the WG, and where naming has its 
own tradition - which I can actually appreciate).


Starting the non-WG list primarily means having discussions on DELEG in 
the IETF, rather than in other forums, and not overloading the DNSOP 
mailing list.



Best,

-- Benno




On Tue, Feb 6, 2024 at 2:37 PM Paul Hoffman > wrote:


Greetings. After the DNSOP interim meeting last week, Warren set up
a new mailing list. Its description is:

=
There is a desire to have better methods for parent zones in the DNS
to advertise DNS nameserver capabilities and zone features to resolvers.

This list discusses mechanisms to provide this support within the
DNS. This includes the ability to provide more information about a
DNS delegation in record(s) at the parent, as well as additional
capabilities beyond the DNS's current NS-style delegation.  Examples
include aliasing delegation with other domain names, delegating
DNSSEC management to operators, specifying encrypted transports, and
so on.
=

The new mailing list is a good place to discuss both the general
idea of new types of delegation for the DNS, as well as specific
proposals like the DELEG proposal which was first discussed at IETF-118.

The list can be found at https://www.ietf.org/mailman/listinfo/dd


Anyone interested in how delegation might work in the future should
join. Thanks!

___
DNSOP mailing list
DNSOP@ietf.org 
https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30

2024-01-24 Thread Benno Overeinder

Dear WG,

We have published an updated agenda for the interim, see 
https://datatracker.ietf.org/doc/agenda-interim-2024-dnsop-01-dnsop-01/.



## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  5 min


### New Business

* Presentation on state of DELEG draft
- https://datatracker.ietf.org/doc/draft-dnsop-deleg/
- 15 minutes

* Legacy resolver compliance testing results
- 5 minutes

* Open discussion points in the draft
- 10 minutes

* Initial reflections on DELEG
- Paul Wouters
- 15 minutes

* Open discussion: discussion and reflection on interim
- 10 minutes

* IETF Process Time
- BoF? New WG? Another hour needed at next IETF



On 19/01/2024 18:13, IESG Secretary wrote:

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).

Agenda:

# DNS Operations (DNSOP) Working Group
## interim-2024-dnsop-01


### 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](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md)
* [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/)

* [Propose 
Slides](https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/session/dnsop)


## Session interim-2024-dnsop-01

* Date: 30 January 2024
* Time: 17:00-18:00 UTC

* 
[MeetEcho](https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f)
* [Jabber](dn...@jabber.ietf.org)
* [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop)
* [Minutes](https://notes.ietf.org/notes-ietf-interim-2024-dnsop-01-dnsop)


## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  5 min


### New Business

* Presentation on state of DELEG draft.
 - 15 minutes

* Legacy resolver compliance testing results.
 - 5 minutes

* Open discussion points in the draft:
 - 10 minutes

* Open Discussiontime for discussions
 - 20 minutes

* IETF Process Time
 * BoF? New WG ? Another Hour Needed at next IETF


Information about remote participation:
https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f



--
A calendar subscription for all dnsop meetings is available at
https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Poll to select DNSOP Interim meeting last week January

2024-01-17 Thread Benno Overeinder

Dear DNSOP WG,

I closed the doodle poll to select a suitable day and time.  The 
selected day and time is *January 30, 2024, 17:00-18:00 UTC*.


I will schedule the interim in the datatracker and more information 
about the interim meeting will appear on the mailing list.



Best regards,

-- Benno


On 12/01/2024 13:34, Benno Overeinder wrote:

Dear DNSOP WG,

The authors and contributors of the DELEG document have made good 
progress since the IETF 118 meeting, where they initially presented 
their ideas.  During the IETF 118 DNSOP meeting, Petr Spacek shared the 
outcomes of the two-day Hackathon session and introduced the initial 
concepts related to DELEG.


For presentation slides, please refer to: 
https://datatracker.ietf.org/meeting/118/materials/slides-118-dnsop-hackaton-118-deleg-rr-proposal-00.


The chairs have engaged with the document's authors and contributors, 
and it appears that the end of January is an opportune time to share the 
progress, current status, and future plans to the DNSOP WG participants. 
  In early February, some of the contributors will meet in person to 
address various issues, and feedback from the DNSOP WG prior to this 
gathering would be highly beneficial.  This timeframe also allows for 
ongoing work on a number of topics that can be presented at the IETF 119 
meeting in March 2024.


To coordinate the interim meeting, we have created a doodle to determine 
a suitable day and time.  Kindly complete the doodle before Tuesday, 
January 16 (end of business day):


* https://doodle.com/meeting/participate/id/b2G7kMJd

The authors and contributors are actively working on drafts available in 
the following GitHub repository: https://github.com/fl1ger/deleg.



Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Poll to select DNSOP Interim meeting last week January

2024-01-12 Thread Benno Overeinder

Dear DNSOP WG,

The authors and contributors of the DELEG document have made good 
progress since the IETF 118 meeting, where they initially presented 
their ideas.  During the IETF 118 DNSOP meeting, Petr Spacek shared the 
outcomes of the two-day Hackathon session and introduced the initial 
concepts related to DELEG.


For presentation slides, please refer to: 
https://datatracker.ietf.org/meeting/118/materials/slides-118-dnsop-hackaton-118-deleg-rr-proposal-00.


The chairs have engaged with the document's authors and contributors, 
and it appears that the end of January is an opportune time to share the 
progress, current status, and future plans to the DNSOP WG participants. 
 In early February, some of the contributors will meet in person to 
address various issues, and feedback from the DNSOP WG prior to this 
gathering would be highly beneficial.  This timeframe also allows for 
ongoing work on a number of topics that can be presented at the IETF 119 
meeting in March 2024.


To coordinate the interim meeting, we have created a doodle to determine 
a suitable day and time.  Kindly complete the doodle before Tuesday, 
January 16 (end of business day):


* https://doodle.com/meeting/participate/id/b2G7kMJd

The authors and contributors are actively working on drafts available in 
the following GitHub repository: https://github.com/fl1ger/deleg.



Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Updated IETF118 DNSOP WG Agenda

2023-11-07 Thread Benno Overeinder

Dear WG,

We have uploaded an updated agenda for the IETF 118 DNSOP sessions on 
Tuesday (this afternoon) and Friday:


* https://datatracker.ietf.org/meeting/118/materials/agenda-118-dnsop-03

No major change for Tuesday (this afternoon) compared to the previously 
published agenda.  With the exception of the Chairs update on WG 
documents, which will be moved to Friday.


For Friday's agenda, we have the Chairs update on WG documents, and we 
have moved the presentation draft-johani-dnsop-delegation-mgmt-via-ddns 
to the beginning of the session at the special request of the presenter 
due to travel schedule.  The draft received some discussion on the 
mailing list and discussion of the document in the WG session seems useful.



Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 118 Call for Agenda Items DNSOP WG

2023-10-24 Thread Benno Overeinder

Dear WG,

This is a friendly reminder of the call for agenda items for the DNSOP 
WG meeting at the upcoming IETF 118.


Tomorrow we will publish the draft agenda for the two sessions scheduled 
for Tuesday afternoon and Friday morning.  To ensure your presentation 
is considered for the draft agenda, please submit your request within 
the next 24 hours by sending us an email or submitting a pull request 
(details below).



Thanks,

Suzanne
Tim
Benno


On 18/10/2023 18:04, Benno Overeinder wrote:

Dear WG,

This is a Call for Agenda Items for the IETF 118 in Prague, Czech Republic.

DNSOP has been allocated two sessions, allowing us more discussion time 
on individual drafts:

- Tuesday 7 November, 17:00-18:00, Congress Hall 3
- Friday 10 November,  9:30-11:30, Congress Hall 2

Please email the chairs  with your requests. *Or* 
drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf118 
look for dnsop-ietf118-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 23 October 2023.

See https://datatracker.ietf.org/meeting/important-dates/:
2023-10-23    Monday    Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D 
Submission Tool https://datatracker.ietf.org/submit/.



Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 118 Call for Agenda Items DNSOP WG

2023-10-18 Thread Benno Overeinder

Scott,

Thank you for your request.  I will add the draft to the agenda requests 
document on GitHub.  I reserve 10 minutes so that there is sufficient 
time for discussion.



Best regards,

-- Benno


On 18/10/2023 20:43, Hollenbeck, Scott wrote:

Benno, could I have 5 minutes to discuss the delegation management aspects of 
my EPP object deletion draft?

Scott


On Oct 18, 2023, at 12:04 PM, Benno Overeinder  wrote:

Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
Dear WG,

This is a Call for Agenda Items for the IETF 118 in Prague, Czech Republic.

DNSOP has been allocated two sessions, allowing us more discussion time on 
individual drafts:
- Tuesday 7 November, 17:00-18:00, Congress Hall 3
- Friday 10 November,  9:30-11:30, Congress Hall 2

Please email the chairs  with your requests. *Or* drop 
us a pull request 
https://secure-web.cisco.com/149owHpmGBU_B7V8mH_TgCyudR9xF1VbH5aA9h-Psj8ulsi510ED9hb6qyyYPJ_Md7egkWdTRSyeubSj75E5nJz79CwgeKyTUHrs6gQbswaG2RwNoEz7BLXHxGD3nr5exsphC5gQ-2EbhtQy5j6D8ydMQBUI-XyAYFEqyl4-8eu5oz42mqIMhq49igYF0y0hr1gZz_Qe5lR6vNOblqj_LzOLKYErprU4mc7X51BE1hBWCV1kEwCqxkkKIvpoXUY2e99tqWi2bSc3vJKzik9A-g2et-E1-3Z6dAr1z94eoIOQ/https%3A%2F%2Fgithub.com%2Fietf-wg-dnsop%2Fwg-materials%2Ftree%2Fmain%2Fdnsop-ietf118
 look for dnsop-ietf118-agenda-requests.md.

Please Note: Draft Submission Deadline is Monday 23 October 2023.

See 
https://secure-web.cisco.com/1UrfXrFzZGAU_Drgorj7IMXlifvNV_OPYhKt9u0mUYdghOPn3Ybq0lnqlEZ373pUcGh5goewC-7ZuTLwQA7wiriBxwnclYtM3a8PGV9C9w0ElSpJwxSNeh8JTDurP2ga13W_fpPxhDlAhvI7zIyZRFFEJm0ZhULx1uvTnCUgL08wVU2hPfSAVdzU1jn0hAclyPAIysAg2bf1G5ToNyeuClHIzfwh27ZqlU4o_f0gHG8ZfJzdwMfX4HN5VigwDgAAqX7zpE2SwIJ-lBsHa2YpNuYth0pBR3YPR1Eg4L9wsVEg/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2Fimportant-dates%2F%3A
2023-10-23MondayInternet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D Submission 
Tool 
https://secure-web.cisco.com/1twdovOD8_6q5tBRbC0RBTYPOg3I47a0F7AKfX6JZC1Juh4I3xCPZfe38ov9YYimxVpryTJ9K8KFDnKj5sOYDWtFyQZqTNCBfmzJ6_iDf_vY7iilhZVxl3Nx1uUpwpshZUhz26SYPpL7rIBcbTSji4jkytFkNofHOkN-kNT3yYNYtdWID98aFtY6B4fRO7FJ0OhG5PZ9-4N8dYGZu-Ul58-5rXLUqLZvQ4GKaJ6W2M1VK68zaqU9ZXcixo4SqSz_xwXNjGiqV9SR3DECyHivzSwv9IwpEREW4OSZ4KfNlooM/https%3A%2F%2Fdatatracker.ietf.org%2Fsubmit%2F


Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://secure-web.cisco.com/17p8ecvmWCiAeQnsNqxe5f1Mf-SwAH4eYf6kOGnOsFtf64uXY3wA9mEvX1Nav0GHkCZgcR9W5nwOCH7prKgMAoDyEtCmX2iYGT4oopo2oPzJsDac-yHVVtq2fsMQpMRbfqHFjwfX19-81Weigi74q7DPDhLhlGH1mESXO6qs_0AnrYCeGtdOiWykax_QWQ_3lcLi1Kb2lq6K8nUeJeGgRZcF1y9XkgjfgYvckmaS_cwVrcHKhQvsEEBgzrqqixiljgGGrNphOXACogthQR7ip7y9HkTNyjy-GzK7FXpx_Kls/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 118 Call for Agenda Items DNSOP WG

2023-10-18 Thread Benno Overeinder

Dear WG,

This is a Call for Agenda Items for the IETF 118 in Prague, Czech Republic.

DNSOP has been allocated two sessions, allowing us more discussion time 
on individual drafts:

- Tuesday 7 November, 17:00-18:00, Congress Hall 3
- Friday 10 November,  9:30-11:30, Congress Hall 2

Please email the chairs  with your requests. 
*Or* drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf118 
look for dnsop-ietf118-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 23 October 2023.

See https://datatracker.ietf.org/meeting/important-dates/:
2023-10-23	Monday	Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D 
Submission Tool https://datatracker.ietf.org/submit/.



Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Publication has been requested for draft-ietf-dnsop-dns-error-reporting-06

2023-10-11 Thread Benno Overeinder via Datatracker
Benno Overeinder has requested publication of 
draft-ietf-dnsop-dns-error-reporting-06 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-dns-error-reporting/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Question regarding RFC 7793

2023-09-19 Thread Benno Overeinder

Dear Von,

As others have noted, your questions and comments are not relevant to 
the IETF DNSOP WG mailing list.


I would ask that you refrain from follow-up emails on off-topic DNSOP 
topics that may be more appropriate for other IETF WGs, or IRTF Reserach 
Groups discussing cryptography (CFRG) and quantum internet (QIRG).


Kind regards,

Benno Overeinder
DNSOP WG co-chair


On 19/09/2023 10:21, Von Johnson wrote:
Protect current Chrome TLS traffic against future quantum cryptanalysis 
by deploying the Kyber768 quantum-resistant key agreement algorithm.


This is a hybrid X25519 + Kyber768 key agreement based on an IETF 
standard. This specification and launch is outside the scope of W3C. 
This key agreement will be launched as a TLS cipher, and should be 
transparent to users.


https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html 
<https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html>
Motivation
In order to protect today’s network traffic against future quantum 
cryptanalytic attacks, we need to begin migrating network security 
protocols, like TLS, to use quantum-resistant cryptography.
TLS will need to update to quantum-resistant cryptography in three 
separate areas:

- Establishing, or agreeing upon a symmetric session key
- Authenticating the server’s identity (e.g. X.509 certificate validation)
- Authenticating the connection was established by the holder of the 
server’s private key



Why does my public IP address have me showing in new York city?

On Mon, Sep 18, 2023, 11:04 PM Paul Wouters <mailto:p...@nohats.ca>> wrote:


On Mon, 18 Sep 2023, Von Johnson wrote:

 > Hello. Any updates?

There will be no updates from this list. This mailing list is about
designing protocols. Other people and vendors implement these. So
if you have a device problem with any application, please contact
the device vendor or application vendor. We just write lots of pages
of RFC text.

Paul

 > On Fri, Sep 15, 2023, 8:36 PM Mark Andrews mailto:ma...@isc.org>> wrote:
 >       Again please make an understandable request. You do not
describe your problem.  Screen shots are not descriptions.
 >
 >       -- Mark Andrews
 >
 >       On 16 Sep 2023, at 10:20, Von Johnson mailto:voni...@gmail.com>> wrote:
 >
 >       Please help me fix. The x25519 exchange is 
 >
 > On Fri, Sep 15, 2023, 7:58 PM Mark Andrews mailto:ma...@isc.org>> wrote:
 >       Please make a understandable request.
 >       --
 >       Mark Andrews
 >
 >       > On 16 Sep 2023, at 05:24, Von Johnson mailto:voni...@gmail.com>> wrote:
 >       >
 >       >
 >       > Please help me return this to normal
 >       > ___
 >       > DNSOP mailing list
 >       > DNSOP@ietf.org <mailto:DNSOP@ietf.org>
 >       > https://www.ietf.org/mailman/listinfo/dnsop
<https://www.ietf.org/mailman/listinfo/dnsop>
 >
 > Screenshot_20230915-201854.png
 >
 >
 >


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

2023-09-14 Thread Benno Overeinder

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 modifications (beyond minor 
editorial), for over a year.


The authors have been interacting with the chairs a few times since the 
beginning of the year, to see if anything needs to be done for the draft 
to advance. In the process, we have been told (in May) that an 
announcement for WGLC readiness would be sent to the WG list, and later 
that WGLC would be started before IETF 118. Once IETF 118 was over, the 
draft was listed first in the Chairs Actions. Now it's been postponed 
again.


We'd like to take the opportunity of this WGLC thread to express our 
confusion about the situation. We would be grateful if the chairs could 
clarify the situation, and identify, on the list, any potential issues 
that might keep draft-ietf-dnsop-dnssec-bootstrapping from advancing so 
that they can be addressed properly (if any).


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 contact you and Nils next week before sending 
the WGLC to the DNSOP mailing list.


Apologies for the delays.  While balancing the work in the DNSOP WG, 
your draft was delayed during the summer months.



Best,

-- Benno


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Publication has been requested for draft-ietf-dnsop-rfc8499bis-08

2023-08-14 Thread Benno Overeinder via Datatracker
Benno Overeinder has requested publication of draft-ietf-dnsop-rfc8499bis-08 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-rfc8499bis/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition

2023-07-26 Thread Benno Overeinder

Hi kc,

On 17/07/2023 21:41, k claffy wrote:



I agree it would greatly help to include the more precise terms.

Note that Scott's current EPP draft is still using this term,
citing the definition in 1912.  Should the term be removed from
Scott's draft, or acknowledged that it is now historic?
If Scott replaces it with another more precise term,
can we get that term in this document so that
future uses can cite this document?

Alternatively, instead of deprecating, the last sentence of that
paragraph could be "Because...and now is not specific or clear as
to the intended meaning, sufficient context may be required to
remove undesired ambiguity."  ( similar to 'validating resolver'? )



Thank you for your remarks.  The chairs acknowledge that more precise 
terms are useful and desirable.  For progress, we decided not to include 
newer terms of different types of broken delegation in the current 
rfc8499bis.  More discussion on these terms is required, and the chairs 
and authors of the document feel that this should be written down in 
another draft.


We would like to invite you or other DNSOP participants to put your 
thoughts in a new draft to discuss with the WG and to come to more 
precise definitions of various broken delegations.  This new draft (RFC) 
can later be referenced by the DNS Terminology document.



Best regards,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition

2023-07-26 Thread Benno Overeinder

Dear WG,

Thank you for your thoughtful feedback during the WGLC for the revised 
lame delegation definition.  With this email, we close the WGLC for 
rfc8499bis.


With the discussion and feedback during the interim and with the WGLC on 
the mailing list, the chairs have determined there is rough consensus on 
the proposed wording on lame delegation, and as it is now included in 
the latest revision of rfc8499bis on datatracker.


After the document shepherd write-up, the document is sent to the IESG 
as the next step.


Best regards,

-- Benno


On 18/07/2023 08:17, Havard Eidnes wrote:

Note that Scott's current EPP draft is still using this term,
citing the definition in 1912.  Should the term be removed
from Scott's draft, or acknowledged that it is now historic?
If Scott replaces it with another more precise term, can we
get that term in this document so that future uses can cite
this document?


[SAH] My draft uses the term in only one place where it describes
practices that can "introduce risks of lame delegation". I'm
inclined to change that sentence to something like "introduce risks
of invalid DNS delegation" to avoid the term completely if it
eliminates the need for a normative reference that doesn't yet
exist.


Don't take this the wrong way -- I'm not picking on you presonally...
But I think this illustrates one of the problems with coming up with
"specific and clear" alternatives to the "lame delegation"
characterization which is also brief, precise, and doesn't have too
wide difference to normal-language usage.

Because...  Even though my first language is not English, I would have
thought that it ought to be possible to distinguish between a "valid"
and an "invalid" delegation without querying for the actual current
operational state wrt. to the given zone, i.e. there has to be some
evident "rule violation" involved.  Quoting the Merriam-Webster
dictionary:

invalid
: not valid:
a : being without foundation or force in fact, truth, or law
   | an invalid assumption
   | declared the will invalid
b : logically inconsequent

The most relevant part here would be "without foundation in ... law",
if we consider the RFCs "law" within this area, which isn't too far-
fetched.

E.g. it would IMHO be "invalid" to use an NS record with a name server
name which contains "_" in its name, because there is at least a deep-
seated convention (if not a rule from ... rfc 952?) that host names,
i.e. names which resolve to A and/or  records (and therefore, by
extension, name server names), should not contain "_" in their owner
name (by default enforced by BIND to this day, when loading an
authoritative zone), i.e. "it explicitly goes against the rules".
(And, yes, I know that not everyone agrees with this rule...)

I would claim the flavour is distinctly different, and that "invalid
delegation" is not a good substitute for "lame delegation".

Regards,

- Håvard

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] New IETF 117 DNSOP WG agenda published

2023-07-21 Thread Benno Overeinder

Dear WG,

A new agenda for the IETF 117 DNSOP WG meeting on Monday, July 24, 
0930-1130 PDT (1630-1830 UTC) has been published, see 
https://datatracker.ietf.org/meeting/117/materials/agenda-117-dnsop-01


The agenda also includes URLs to MeetEcho and Zulip.

Best regards,

Suzanne
Tim
Benno


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] WGLC rfc8499bis for revised lame delegation definition

2023-07-17 Thread Benno Overeinder

Dear WG,

With the DNSOP interim meeting last June, we reworded the definition of 
"lame delegation".  This new definition of "lame delegation" has been 
shared on the mailing list and included by the document authors in the 
latest revision of the rfc8499bis draft, 
https://author-tools.ietf.org/iddiff?url2=draft- ietf-dnsop-rfc8499bis-08.


This one-week Working Group Last Call is only about the definition of 
"lame delegation".  As mentioned above, the wording is the result of the 
interim meeting, where it was identified that the original definition of 
"lame delegation" does not cover current operational issues and that 
more precise terms are preferred.


We believe the current wording reflects the views shared on the mailing 
list over the past two months, and we ask for confirmation.  If there 
are strong objections to the current definition in revision -08, we 
return to the original rfc8499 definition.  Regardless of the outcome, 
after this WGLC the document will be forwarded to the IESG for publication.


This WGLC will end on Monday, 24 July.

Best regards,

Benno
for the DNSOP co-chairs

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

2023-07-17 Thread Benno Overeinder

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 incorporates the 
feedback.  Some issues may need to be addressed in a subsequent revision 
before the document is sent to the IESG.  We are coordinating this 
further with the authors.


Best regards,

-- Benno

On 11/07/2023 00:35, Viktor Dukhovni wrote:

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 option and the monitoring agent.


I agree that a monitoring agent can specify a domain that may include
a separator as the least significant label. However, it also requires
the monitoring agent to understand that it should sometimes include
this separator, and that it may be redundant at other times.


If all the monitoring agent's "customers" (authoritative servers that
return its "suffix" in the new option) are informed to signal an
"_er.agent.example" name, there's no "sometimes".  The agent, by mutual
agreement with the nameservers it supports can choose whatever suffix
format meets its needs, fixed across all customers, or customer-specific.

I haven't yet seen a reason to insist on a fixed suffix pattern.  The
resolver just stutters back the suffix it was handed by the
authoritative server's extension payload.  What problem does mandating
the least significant label of the suffix solve, that can't be solved by
just signalling the desired suffix, special label and all?


It assumes that those running the authoritative server that returns
the agent domain and those that run the reporting agent are in sync.
Those are a lot of assumptions.


If they're not in sync, surely reporting will be broken, whether or not
an "_er" suffix label is used.


  Why should resolvers have to be responsible for this?


Because this separating label is trivial to include and avoids a lot of hassle.


The hassle in question remains unclear.  I see two relevant/likely
deployment models:

 * Self-hosted reporting, directly by the authoritative server:

 - Error reports are special by virtue of a dedicated qname
   suffix and perhaps qtype.

 - No special coördination required, the server both publishes
   and consumes the error reporting suffix.

  * Outsourced/centralised reporting, via server IPs dedicated to
error report processing.

  - Here again no need for "_er", because all queries are
presumptively error reports, and if the signal from the
"customer" auth server was wrong (whether or not an "_er"
label is included) the error report will not be handled
correctly.

   - If the signal has the correct (mutually agreed) suffix,
 again no problem.

   - And of course the monitoring agent can specify the use
 of "_er" (or whatever) if that's convenient.

What use-case actually benefits from the "_er" LSL (least-significant
label) in the signal?  How is this benefit not obtained by mutual
agreement between the monitoring agent and its customers?


The sole purpose of the leading “least-significant” “_er” is to
distinguish between qname-minimized queries (for lack of a better
term) and “full” queries. I understand that you argue that a
monitoring agent can determine this without the _er labels (as
described below), but that seem suboptimal to me.


The qname minimised query (whether or not a dedicated qtype is used)
will be for "A" or "NS" records, not TXT or the dedicated qtype, so
there's no need for "_er" in the first label, the qtype is sufficient.


RFC9156 contains no hard requirement to use A/NS. So I’m not confident
that all current and future qname-minimisation implementations use
A/NS.


This is where this document can specify that qname minimised error
reports MUST use a qtype other than the qtype for the final error
report.


However, to avoid forwarding junk reports to the monitoring agent, a
resolver may well sensibly choose to not forward such queries, and
only source them internally.


I’m not following.


If the qtype is "TXT", then an open resolver is easily subject to
proxying forged error reports purporting errors that the resolver did
not observe.  Some client of the open resolver sends an explicit query
for:

 . IN TXT ?

which then looks like an error report from *that* resolver to the
monitoring agent.  If instead we have a dedicated qtype for error
reports, it becomes a simple matter of refusing to iterate queries for

 . IN  ?

Any resolver wanting to report an error must do so directly, not via a
forwarder.  Especially because the 

[DNSOP] IETF 117 Call for Agenda Items DNSOP WG

2023-06-21 Thread Benno Overeinder

Dear WG,

This is a Call for Agenda Items for the IETF 117 in San Francisco, 
California.


Please email the chairs  with your requests. *Or* 
drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf117 
look for dnsop-ietf117-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 10 July 2023.

See https://datatracker.ietf.org/meeting/important-dates/:
2023-06-23  Friday  Preliminary Agenda published for comment.
2023-06-30  Friday  Final agenda to be published.
2023-07-10	Monday	Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D 
Submission Tool https://datatracker.ietf.org/submit/.



Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2023-06-20

2023-06-20 Thread Benno Overeinder

Dear WG,

We have agenda, slides and meeting details for Meetecho, Zulip, etc., 
available on datatracker: 
https://datatracker.ietf.org/meeting/interim-2023-dnsop-01/session/dnsop


Best,

-- Benno

On 06/06/2023 16:19, IESG Secretary wrote:

The Domain Name System Operations (dnsop) WG will hold a virtual interim
meeting on 2023-06-20 from 20:00 to 21:00 Europe/Amsterdam (18:00 to 19:00
UTC).

Agenda:
## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  5 min


### Current Working Group Business

*   DNS Terminology and definition "lame delegation"
 - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/
 - WG Chairs, Paul Hoffman and Kazunori Fujiwara, 55 min
 - Chairs Action:


Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=7e86a1ea-71f7-40c0-8c34-eb16a1a57a6e



--
A calendar subscription for all dnsop meetings is available at
https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Coming soon: WG interim meeting on the definition of "lame delegation"

2023-06-19 Thread Benno Overeinder

Hi all, Paul,

On 17/06/2023 22:59, Paul Hoffman wrote:
Greetings again. A bunch of you have opinions in this area. In advance 
of our WG interim meeting on Tuesday, it would be grand if people with 
opinions would review those opinions and review the threads on the list 
where other peoples' opinions were expressed. This will make our time 
together in the interim meeting more valuable.


Thank you for reminding the WG to go over the discussion threads and 
review the opinions expressed.


I will prepare two to three slides summarizing the discussions, 
including the most recent discussion on the meaning of "lame," to help 
focus the meeting.



FWIW, I'm glad I'm not the one who will be deciding consensus here; the 
chairs will be.


You are welcome Paul.  :-)

Looking forward to a productive meeting.

Best,

-- Benno



Begin forwarded message:


*From: *IESG Secretary 
*Subject: **[Ext] [DNSOP] Domain Name System Operations (dnsop) WG 
Virtual Meeting: 2023-06-20*

*Date: *June 6, 2023 at 7:19:23 AM PDT
*To: *"IETF-Announce" 
*Cc: *dnsop@ietf.org

The Domain Name System Operations (dnsop) WG will hold a virtual interim
meeting on 2023-06-20 from 20:00 to 21:00 Europe/Amsterdam (18:00 to 19:00
UTC).

Agenda:
## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  5 min


### Current Working Group Business

*   DNS Terminology and definition "lame delegation"
   - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/
   - WG Chairs, Paul Hoffman and Kazunori Fujiwara, 55 min
   - Chairs Action:


Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=7e86a1ea-71f7-40c0-8c34-eb16a1a57a6e



--
A calendar subscription for all dnsop meetings is available at
https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

2023-06-16 Thread Benno Overeinder

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 that 
the document is ready for submission to IESG for publication.



Thanks!

-- Benno


On 08/06/2023 11:59, Benno Overeinder wrote:

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: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/.


The Current Intended Status of this document is: Standards Track.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please 
speak out with your reasons.

Supporting statements that the document is ready are also welcome.

This starts a two week Working Group Last Call process, and ends on: 
June 22nd, 2023.


Thanks,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

2023-06-08 Thread 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.


Current versions of the draft is available here: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/.


The Current Intended Status of this document is: Standards Track.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please 
speak out with your reasons.

Supporting statements that the document is ready are also welcome.

This starts a two week Working Group Last Call process, and ends on: 
June 22nd, 2023.


Thanks,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] DNSOP WG Interim June 2023 planning: draft-ietf-dnsop rfc8499bis and lame delegation

2023-06-06 Thread Benno Overeinder

Dear WG,

From the Doodle poll, we have selected the following day and time:

Tuesday June 20, 18:00-19:00 UTC.

We will post the interim meetecho details to the mailing list later today.

Best regards,

Suzanne, Tim and Benno


On 30/05/2023 17:31, Benno Overeinder wrote:

Hi WG,

Gentle reminder to fill in the doodle to schedule the interim in June.

Will extend the poll until Thursday, June 1!


-- Benno


On 24/05/2023 16:11, Benno Overeinder wrote:

Dear WG,

As mentioned earlier on the mailing list, the chairs are planning an 
interim meeting in June to discuss the three options on how to proceed 
with draft-ietf-dnsop-rfc8499bis wrt. lame delegation:


1) Stick with the current text in the document – the original 
definition from RFC8499 plus a note that "These early definitions do 
not match the current use of the term "lame delegation", but there is 
no consensus on what a lame delegation is."
A possible follow-up to this is for someone to start a WG consensus 
document on "lame", which can update 8499bis.
2) We still find a rough consensus on the definition proposed in the 
"Meaning of lame delegation" email thread, and the WG can agree that 
this is a definition useful to DNS engineers/operators.
3) Withdraw the document from WGLC so we can add definitions.  Do not 
propose any new terms and definitions at this stage if we choose this 
option.



Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/az7Z5AOb

The options for the time slots are a compromise for 
CEST/EDT/PDT/AEST/JST.


We will close the Doodle poll at the end of Tuesday 30 May.

Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] DNSOP WG Interim June 2023 planning: draft-ietf-dnsop rfc8499bis and lame delegation

2023-05-30 Thread Benno Overeinder

Hi WG,

Gentle reminder to fill in the doodle to schedule the interim in June.

Will extend the poll until Thursday, June 1!


-- Benno


On 24/05/2023 16:11, Benno Overeinder wrote:

Dear WG,

As mentioned earlier on the mailing list, the chairs are planning an 
interim meeting in June to discuss the three options on how to proceed 
with draft-ietf-dnsop-rfc8499bis wrt. lame delegation:


1) Stick with the current text in the document – the original definition 
from RFC8499 plus a note that "These early definitions do not match the 
current use of the term "lame delegation", but there is no consensus on 
what a lame delegation is."
A possible follow-up to this is for someone to start a WG consensus 
document on "lame", which can update 8499bis.
2) We still find a rough consensus on the definition proposed in the 
"Meaning of lame delegation" email thread, and the WG can agree that 
this is a definition useful to DNS engineers/operators.
3) Withdraw the document from WGLC so we can add definitions.  Do not 
propose any new terms and definitions at this stage if we choose this 
option.



Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/az7Z5AOb

The options for the time slots are a compromise for CEST/EDT/PDT/AEST/JST.

We will close the Doodle poll at the end of Tuesday 30 May.

Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] DNSOP WG Interim June 2023 planning: draft-ietf-dnsop rfc8499bis and lame delegation

2023-05-24 Thread Benno Overeinder

Dear WG,

As mentioned earlier on the mailing list, the chairs are planning an 
interim meeting in June to discuss the three options on how to proceed 
with draft-ietf-dnsop-rfc8499bis wrt. lame delegation:


1) Stick with the current text in the document – the original definition 
from RFC8499 plus a note that "These early definitions do not match the 
current use of the term "lame delegation", but there is no consensus on 
what a lame delegation is."
A possible follow-up to this is for someone to start a WG consensus 
document on "lame", which can update 8499bis.
2) We still find a rough consensus on the definition proposed in the 
"Meaning of lame delegation" email thread, and the WG can agree that 
this is a definition useful to DNS engineers/operators.
3) Withdraw the document from WGLC so we can add definitions.  Do not 
propose any new terms and definitions at this stage if we choose this 
option.



Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/az7Z5AOb

The options for the time slots are a compromise for CEST/EDT/PDT/AEST/JST.

We will close the Doodle poll at the end of Tuesday 30 May.

Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] RFC8499bis path forward after extended WGLC

2023-05-19 Thread Benno Overeinder

Dear WG,

The extended WGLC for rfc8499-bis did not conclude with rough consensus 
on either of the two proposed definitions of the term "lame delegation".


There was some consensus in a subthread on one of the proposed 
definitions, earlier formulated on the mailing list, see the original 
thread 
https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/. 
 For readability, I will include the proposed definition again:
"A lame delegation is said to exist when one or more authoritative 
servers designated by the delegating NS RRset or by the child's apex NS 
RRset answers non-authoritatively for a zone".


In another subthread, new terms and definitions appeared because the 
definition above was not specific enough, but this thread didn't lead to 
a specific definition.


There are now three paths forward:
1) Stick with the current text in the document – the original definition 
from RFC8499 plus a note that "These early definitions do not match the 
current use of the term "lame delegation", but there is no consensus on 
what a lame delegation is."
A possible follow-up to this is for someone to start a WG consensus 
document on "lame", which can update 8499bis.
2) We still find a rough consensus on the definition proposed in the 
"Meaning of lame delegation" email thread, and the WG can agree that 
this is a definition useful to DNS engineers/operators.
3) Withdraw the document from WGLC so we can add definitions.  Do not 
propose any new terms and definitions at this stage if we choose this 
option.


The third option is the least desirable outcome since the document is 
already this far in the process and has seen many reviews and edits.


In order for the WG to decide how to proceed, we plan to schedule an 
interim meeting in June and discuss the three options with the WG.



Thank you,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] WGLC rfc8499bis one week extension for lame delegation definition

2023-05-06 Thread Benno Overeinder

Dear WG,

The extended WGLC rfc8499bis has been closed.  With the specific 
question from the chairs, the WG did not find consensus on either of the 
two proposed definitions of the term "lame delegation".  In one 
subthread of the discussion there was some convergence towards a 
definition, but in other subthreads we saw suggestions for new terms and 
definitions, which was not the question to the working group.


The chairs are taking the current WGLC discussion into their evaluation 
of how to proceed and will share our way forward with the document in 
the first half next week.


In the meantime, please continue the discussion.

Best regards,

-- Benno


On 27/04/2023 22:05, Benno Overeinder wrote:

Dear WG,

The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion
on lame delegation did not find consensus, but two specific suggestions
were put forward.  We would like to include one of them in rfc8499bis if
we can get consensus to do so.

The chairs are seeking input on the following two suggestions:

* Either we leave the definition of “lame delegation” as it is with the
   comment that no consensus could be found, or

* alternatively, we include a shorter definition without specific
   examples.

1) Leaving the definition of lame delegation as in the current
    draft-ietf-dnsop-rfc8499bis, and including the addition by the
    authors that:

    "These early definitions do not match current use of the term "lame
    delegation", but there is also no consensus on what a lame delegation
    is."  (Maybe change to ... no consensus what *exactly* a lame
    delegation is.)

2) Update the definition as proposed by Duane and with the agreement of
    some others (see mailing list 
https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/):


    "A lame delegation is said to exist when one or more authoritative
    servers designated by the delegating NS RRset or by the child's apex
    NS RRset answers non-authoritatively [or not at all] for a zone".

The chairs ask the WG to discuss these two alternative definitions of
the term "lame delegation".  We close the consultation period on
Thursday 4 May.

Regards,

Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] WGLC rfc8499bis one week extension for lame delegation definition

2023-04-27 Thread Benno Overeinder

Dear WG,

The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion
on lame delegation did not find consensus, but two specific suggestions
were put forward.  We would like to include one of them in rfc8499bis if
we can get consensus to do so.

The chairs are seeking input on the following two suggestions:

* Either we leave the definition of “lame delegation” as it is with the
  comment that no consensus could be found, or

* alternatively, we include a shorter definition without specific
  examples.

1) Leaving the definition of lame delegation as in the current
   draft-ietf-dnsop-rfc8499bis, and including the addition by the
   authors that:

   "These early definitions do not match current use of the term "lame
   delegation", but there is also no consensus on what a lame delegation
   is."  (Maybe change to ... no consensus what *exactly* a lame
   delegation is.)

2) Update the definition as proposed by Duane and with the agreement of
   some others (see mailing list 
https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/):


   "A lame delegation is said to exist when one or more authoritative
   servers designated by the delegating NS RRset or by the child's apex
   NS RRset answers non-authoritatively [or not at all] for a zone".

The chairs ask the WG to discuss these two alternative definitions of
the term "lame delegation".  We close the consultation period on
Thursday 4 May.

Regards,

Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] can someone forward this to benno?

2023-04-26 Thread Benno Overeinder

Thank you Paul.

The problem seems to be with DKIM and header rewriting by 
ietfa.amsl.com. We are in contact to resolve this, but it doesn't seem 
easy. Turning off DKIM on my side doesn't seem like an option, but we're 
working on an alternative solution.


If anyone else has this problem using dnsop-cha...@ietf.org and gets a 
message back saying the email could not be delivered, please email me 
directly.  It will arrive.  (At least one other IETF participant 
experienced the same problem and contacted me.)


Best,

-- Benno


On 26/04/2023 18:49, Paul Vixie wrote:

i don't know why it was rejected as spam but his sysadmin might.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 116 DNSOP WG agenda published

2023-03-16 Thread Benno Overeinder

All,

The DNSOP WG agenda for the IETF 116 was published yesterday, see 
https://datatracker.ietf.org/doc/agenda-116-dnsop/.


We have a full agenda of almost 2 hours:
- DNSOP WG chairs update and administrativia: 25 min
- Current DNSOP WG documents: 30 min
- drafts for consideration: 50 min
- time permitting: 10 min

We look forward to seeing you on site or remotely in the DNSOP WG!

Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Working Group Last Call for "DNS Terminology" (draft-ietf-dnsop-rfc8499bis)

2023-03-10 Thread Benno Overeinder

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 
https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-05.html#section-7-2.36)
2) definition of degree of kinship in context of the term "unrelated 
name server".


Feedback 1) can be easily incorporated in the document.

For feedback 2), the chairs agree that the term "unrelated" is a 
general/everyday language word and not very specific.  We tried to come 
up with a better, more specific word, also with help from others, but we 
and the WG could not come up with a better term.


While the degree of kinship is more specific and helps us define the 
term "unrelated", we feel it adds some complexity to the glue definition 
and is otherwise not used/relevant in the document.  Therefore, we 
suggest that the authors stick to the use of the term "unrelated name 
server".


See for context the following email thread, 
https://mailarchive.ietf.org/arch/msg/dnsop/PBr7-ZMVYiqEzFalOFAQaMnPpFs/.


The document is now in WG consensus and waiting for write up state.

Best regards,

-- Benno


On 10/03/2023 18:21, Benno Overeinder wrote:

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 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 Working Group on bailiwick 
and in-domain/sibling name servers terminology, the authors and 
chairs believe this document has reached the stage of being ready for 
Working Group Last Call.


Due to normative reference to draft-ietf-dnsop-glue-is-not-optional 
(because that draft explains what to do with the definitions in this 
draft), both drafts will go to WGLC together.  (WGLC for 
glue-is-not-optional will be issued early next week.)



This starts a Working Group Last Call for: draft-ietf-dnsop-rfc8499bis.

Current versions of the draft is available here: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/.


The Current Intended Status of this document is: Best Current Practice.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please 
speak out with your reasons.

Supporting statements that the document is ready are also welcome.


This starts a two week Working Group Last Call process, and ends on: 
March 3rd 2023


Thanks,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Working Group Last Call for "DNS Terminology" (draft-ietf-dnsop-rfc8499bis)

2023-03-10 Thread Benno Overeinder

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 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 Working Group on bailiwick and 
in-domain/sibling name servers terminology, the authors and chairs believe this 
document has reached the stage of being ready for Working Group Last Call.

Due to normative reference to draft-ietf-dnsop-glue-is-not-optional (because 
that draft explains what to do with the definitions in this draft), both drafts 
will go to WGLC together.  (WGLC for glue-is-not-optional will be issued early 
next week.)


This starts a Working Group Last Call for: draft-ietf-dnsop-rfc8499bis.

Current versions of the draft is available here: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/.

The Current Intended Status of this document is: Best Current Practice.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak out 
with your reasons.
Supporting statements that the document is ready are also welcome.


This starts a two week Working Group Last Call process, and ends on: March 3rd 
2023

Thanks,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

2023-03-10 Thread Benno Overeinder

Hi Peter,


On 06/03/2023 23:31, Peter Thomassen wrote:
I just went over the updated wording in draft-ietf-dnsop-rfc8499bis-05, 
and the paragraph 
https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-05.html#section-7-2.36 caught my attention.


It uses the term "zone origin", but doesn't say whether it relates to 
the parent or child zone. I was assuming the child, and it took me a 
while to make sense of it (until I noticed that it must mean the parent).


Thank you for your clarification.  This feedback will incorporated in a 
next revision of the document.



I'd like to suggest clarifying that paragraph. That brings me to your 
question below:


On 11/25/22 14:38, Benno Overeinder wrote:
Thank you for your input and your suggestion to come up with a more 
specific terminology for the "historical" out-of-bailiwick term.  In 
the definition of in-domain and sibling domain, you suggest using the 
0th and 1st order in the definition?  And for out-of-bailiwick use a 
term like "2nd+ order nameservers"?


Pretty much. Here is a version of it that's hopefully better to grasp 
than my previous post, and has examples.


     There are various degrees of relationship between a delegation and its
     name servers.  The degree depends on where theirdelegation paths from
     the root intersect with the delegated zone's delegation path.

     To establish the degree of relationship for a given name server, count
     how many zone cuts in the delegation path from the root to the zone of
     interest are shared by the delegation path of that name server.  
This is
     a measure of unrelatedness between the zone and its name server, 
called

     "degree ofkinship".

     If the degree is 0, then the NS hostname is "in-domain".  For example,
     a delegation for "child.example.com" might have an in-domain name 
server

     called "ns.child.example.com".  The name server name has all the zone
     cuts from the root that the delegated domain has.

     If this number is non-zero, then the delegation path to the name 
server

     name branches off from the zone's delegation path.  The "degree of
     kinship" tells you how many zone cuts above the zone of interest this
     happens.  For example, a delegation for "child.example.com" in the
     "example.com" zone might have a "sibling domain" name server called
     "ns.another.example.com", which does not share the final zonecut of
     "child.example.com".  The branching is at "example.com", and the 
degree

     of kinship is 1.

     An unrelated relationship is one where the degree of kinship is larger
     than 1.  For example, the delegation for "example.jp" might have an
     name server "ns.example.com".  The delegation paths alreadydiverge at
     the root, 2 zone cuts above "example.jp".

This may be a bit verbose, but I'm sure it can be reduced to four 
paragraphs, if needed, that are easier to digest than the four 
paragraphs the draft currently has for these definitions.


While writing the above, I again stumbled over the term "unrelated name 
server". It could mean all kinds of things, such as a name server that 
doesn't claim to be authoritative. People don't always have the 
definitions at hand, and I think using that term is a risky choice 
(especially as "unrelated" is a word from every-day language).


Thank you for further explaining your idea and concept of degree of 
kinship.  The chairs agree that the term "unrelated" is a 
general/everyday language word and not very specific.  We tried to come 
up with a better, more specific word, also with help from others, but we 
and the WG could not come up with a better term.


While the degree of kinship is more specific and helps us define the 
term "unrelated", we feel it adds some complexity to the glue definition 
and is otherwise not used/relevant in the document.  Therefore, we 
suggest that the authors stick to the use of the term "unrelated name 
server".


Best regards,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 116 Call for Agenda Items DNSOP WG

2023-03-01 Thread Benno Overeinder

Dear WG,

This is a Call for Agenda Items for the IETF 116 in Yokohama, Japan.

Please email the chairs  with your requests. *Or* 
drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf116 
look for dnsop-ietf116-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 13 March 2023.

See https://datatracker.ietf.org/meeting/important-dates/:
2023-03-13	Monday	Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D 
Submission Tool https://datatracker.ietf.org/submit/.



Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Working Group Last Call for "DNS Terminology" (draft-ietf-dnsop-rfc8499bis)

2023-02-17 Thread Benno Overeinder

Dear DNSOP WG,

Following the latest consultation with the Working Group on bailiwick 
and in-domain/sibling name servers terminology, the authors and chairs 
believe this document has reached the stage of being ready for Working 
Group Last Call.


Due to normative reference to draft-ietf-dnsop-glue-is-not-optional 
(because that draft explains what to do with the definitions in this 
draft), both drafts will go to WGLC together.  (WGLC for 
glue-is-not-optional will be issued early next week.)



This starts a Working Group Last Call for: draft-ietf-dnsop-rfc8499bis.

Current versions of the draft is available here: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/.


The Current Intended Status of this document is: Best Current Practice.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please 
speak out with your reasons.

Supporting statements that the document is ready are also welcome.


This starts a two week Working Group Last Call process, and ends on: 
March 3rd 2023


Thanks,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

2023-02-16 Thread Benno Overeinder

All,

We would like to point out that discussions should be respectful and 
about technical issues and not about the person.


Note that the DNSOP WG Chairs ensure that the IETF Guidelines for 
Conduct, RFC 7154, are adhered to.


Thanks,

Benno, Suzanne and Tim
co-chairs DNSOP WG

On 16/02/2023 06:01, Masataka Ohta wrote:

Mark Andrews wrote:


It advises against a new QTYPE that returns multiples types and gives
the reasoning behind the decision.  That is not the same as prohibiting
QDCOUNT > 1.


That's in my first mail.

But, we are in subthread on my second mail.

All of you should learn to read the rfcs and, then,
mails you are responding, before writing huge amount
of abstract nonsenses.

     Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Status of draft-ietf-dnsop-rfc8499bis

2023-01-20 Thread Benno Overeinder

Thank you Paul and Kazunori.

The chairs agree that both drafts (glue-is-not-optional and rfc8499bis) 
should go to WG Last Call together.  We will coordinate this further 
with the authors of both documents to move forward with the WGLC.


Best,

-- Suzanne, Tim and Benno

On 20/01/2023 16:34, Paul Hoffman wrote:

Greetings again. Kazunori and I have just submitted -05 of this draft to 
incorporate the consensus from the WG on how to talk about the types of glue. 
Please see the diff for the specific wording that was used to reflect the WG 
consensus. Note that we now normatively reference 
draft-ietf-dnsop-glue-is-not-optional because that draft explains what to do 
with the definitions in this draft.

(I have no idea why there are those "skipping" sections; I'll report the bug.)

This is now ready for WG Last Call. The chairs should move 
draft-ietf-dnsop-glue-is-not-optional and draft-ietf-dnsop-rfc8499bis to WG 
Last Call together.

--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

2022-11-25 Thread Benno Overeinder

Hi Peter,

On 04/11/2022 00:52, Peter Thomassen wrote:



On 11/3/22 17:44, Benno Overeinder wrote:

Questions:

1b.  Does this also mean changing the definition of "out-of-bailiwick"
  to a more historical definition as well?  Or do we still need a
  term for in-domain name server, sibling domain name server and ...
  (alternative for out-of-bailiwick)?

  Is "unrelated name server" a term that can be used?
I think "unrelated name server" is easy to misunderstand, as the term is 
unclear about what kind of relation it refers to. For example, a naive 
interpretation of an "unrelated" nameserver may be a sibling nameserver 
that is operated by another (unrelated) DNS provider. I would think that 
such misunderstandings will be frequent when this term is introduced.


Think about various degrees of relationship, the following observation 
occurred to me.


- in-domain nameservers are, in a sense, related to the 0th order (no 
delegations not shared between zone and NS),


- sibling nameservers are related to 1st order (one delegation not 
shared, namely the one from the parent to the NS zone),


- out-of-bailiwick nameservers are related to 2nd or higher order 
(example.com with ns1.example.net has 2 delegations not shared, namely 
the net delegation and the example.net delegation).


One possible would thus be to establish terminology in terms of n-th 
order. E.g., sibling NS is a "1st-order foreign delegation NS" or 
something like that. -- I'm aware this sounds very bumpy, and it's 
simply what just occurred to me, not at all thought through.


I'm also not trying to crash the interim results, just sharing the 
observation. If not helpful, ignore. :)


Thank you for your input and your suggestion to come up with a more 
specific terminology for the "historical" out-of-bailiwick term.  In the 
definition of in-domain and sibling domain, you suggest using the 0th 
and 1st order in the definition?  And for out-of-bailiwick use a term 
like "2nd+ order nameservers"?


I'd love to hear from other DNSOP participants if there is any support 
for Peter or any other suggestions for a good, more specific alternative 
term for out-of-bailiwick?


-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

2022-11-25 Thread Benno Overeinder

Hi Libor,

On 04/11/2022 12:15, libor.peltan wrote:

Hi,

I'm trying to understand this, but not sure if I do. What I see is:

"The definition of bailiwick (in-b, out-of-b) is messed up and any 
further use of it in normative documents will probably lead to 
ambiguities. The proposed tactic is to stop using it and define a new 
term (in-domain) which means the same but it's definition will be 
precise and relevant in current state of DNS."


If my understanding above is matching reality, then (note the 
implication) I agree with the proposed tactic.


Indeed, your understanding is correct that is the intent of the question 
to the WG.


Best,

-- Benno


Dne 03. 11. 22 v 22:44 Benno Overeinder napsal(a):

Dear WG,

With the DNSOP rfc8499bis interim in September, we had the action 
point to send two questions to the DNSOP WG to find consensus on the 
bailiwick and glue discussion.


You can find the interim meeting material here 
https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop and the recording of session here https://youtu.be/wY7-f40lDgU.


We will send two questions to the WG, in two separate emails to keep 
the discussion separate.  This email is the first question to the WG 
that addresses the definition of bailiwick.



Questions:

1. Move Bailiwick to historical.

1a.  During the interim, there was a (feeling of) consensus to drop a
 formal definition of "bailiwick", but keep a historical definition
 (how it was interpreted by) of "bailiwick". Also do not define and
 use the term "in-bailiwick".

 Suggested terms to use are "in-domain name server" and "sibling
 domain domain server", as defined and used in
 draft-draft-ietf-dnsop-glue-is-not-optional, section 2.1 and 2.2.

 [The latest draft of glue-is-not-optional does provide a definition
 of sibling domain name servers, but it does not really provide one
 for in-domain name servers.  That would be easy to fix.]

1b.  Does this also mean changing the definition of "out-of-bailiwick"
 to a more historical definition as well?  Or do we still need a
 term for in-domain name server, sibling domain name server and ...
 (alternative for out-of-bailiwick)?

 Is "unrelated name server" a term that can be used?


Thanks,

-- Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Subject: request for adoption: draft-edns-presentation

2022-11-24 Thread Benno Overeinder

Hi Libor and Tom,

Thank you for submitting the draft.  The first step is to receive 
feedback from the WG on the mailing list and possibly with a 
presentation of the draft during a DNSOP WG meeting.


If there is sufficient interest from the WG, the DNSOP chairs will start 
with a formal call for adoption of the document.  So for now, WG please 
provide feedback on the draft and express support that this work is 
relevant to WG.  However, support for adoption is not (yet) polled by 
the WG chairs.



Cheers,

-- Benno



On 23/11/2022 20:25, libor.peltan wrote:

Hi DNSOP,
we have prepared a specification document (see below), which fills a gap 
that appears to be missing currently — The EDNS(0) textual and JSON format.

It also fixes a "specification bug" in an existing and related RFC.

We believe this draft is pretty much complete and have a first PoC 
implementation ready. While it would be viable to submit it 
individually, we believe that the adoption by the WG would be generally 
beneficial.


We would also welcome any improvement suggestions and useful 
corrections. However, fearing discussion loops arguments about details, 
we encourage to moderate discussion of details, such as if some fields 
in a specific option shall be separated by commas or slashes.
This document is full of design decisions that might be differently 
appealing to everyone. The format might seem complicated, but the goal 
was best possible human readability.
And the more general (and important) goal is to make the standard 
useful, so that it gets adopted by implementations.


Thank you for reading the document and for considering its adoption,
Libor & Tom



 Přeposlaná zpráva 
Předmět: 	New Version Notification for 
draft-peltan-edns-presentation-format-00.txt

Datum:  Wed, 23 Nov 2022 11:20:19 -0800
Od: internet-dra...@ietf.org
Komu:   Libor Peltan , Tom Carpay 




A new version of I-D, draft-peltan-edns-presentation-format-00.txt
has been successfully submitted by Libor Peltan and posted to the
IETF repository.

Name: draft-peltan-edns-presentation-format
Revision: 00
Title: EDNS Presentation and JSON Format
Document date: 2022-11-23
Group: Individual Submission
Pages: 19
URL: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format



Abstract:
This document describes textual and JSON representation format of
EDNS option. It also modifies the escaping rules of JSON
representation of DNS messages, previously defined in RFC8427.



The IETF Secretariat



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition

2022-11-03 Thread Benno Overeinder

Dear WG,

With the DNSOP rfc8499bis interim in September, we had the action point 
to send two questions to the DNSOP WG to find consensus on the bailiwick 
and glue discussion.


You can find the interim meeting material here 
https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop 
and the recording of session here https://youtu.be/wY7-f40lDgU.


This is the second email to the WG, focussing on the definition of glue.

Questions:

2. Definition of Glue provided by Duane Wessels on the DNSOP WG mailing
   list:

   "Glue is non-authoritative data in a zone that is transmitted in the
   additional section of a referral response on the basis that the data
   might be necessary for resolution to proceed at the referred name
   servers."

   On the mailing list, we have seen a discussion about "necessary"
   versus "useful".  In this context glue is defined to be exclusively
   A/ records (traditional understanding), or do we also consider
   other RRtypes to be glue, e.g. SCVB/HTTPS or DS records?  Concern is
   that "useful" may lead to a definition that is too broad.

Taking the last point a step further: if the definition is expanded and 
glue-is-not-optional becomes a requirement then responses may grow in 
size and exceed fragmentation/truncation thresholds and lead to more TCP.


Remark by WG during interim meeting: One might need a registry for 
RRtypes being glue (in the future).


Thanks,

-- Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

2022-11-03 Thread Benno Overeinder

Dear WG,

With the DNSOP rfc8499bis interim in September, we had the action point 
to send two questions to the DNSOP WG to find consensus on the bailiwick 
and glue discussion.


You can find the interim meeting material here 
https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop 
and the recording of session here https://youtu.be/wY7-f40lDgU.


We will send two questions to the WG, in two separate emails to keep the 
discussion separate.  This email is the first question to the WG that 
addresses the definition of bailiwick.



Questions:

1. Move Bailiwick to historical.

1a.  During the interim, there was a (feeling of) consensus to drop a
 formal definition of "bailiwick", but keep a historical definition
 (how it was interpreted by) of "bailiwick". Also do not define and
 use the term "in-bailiwick".

 Suggested terms to use are "in-domain name server" and "sibling
 domain domain server", as defined and used in
 draft-draft-ietf-dnsop-glue-is-not-optional, section 2.1 and 2.2.

 [The latest draft of glue-is-not-optional does provide a definition
 of sibling domain name servers, but it does not really provide one
 for in-domain name servers.  That would be easy to fix.]

1b.  Does this also mean changing the definition of "out-of-bailiwick"
 to a more historical definition as well?  Or do we still need a
 term for in-domain name server, sibling domain name server and ...
 (alternative for out-of-bailiwick)?

 Is "unrelated name server" a term that can be used?


Thanks,

-- Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] draft-homburg-add-codcp potential new work for WG?

2022-10-17 Thread Benno Overeinder

Dear WG,

The DNSOP WG chairs welcome feedback on the draft 
draft-homburg-add-codcp, Control Options For DNS Client Proxies 
(https://datatracker.ietf.org/doc/draft-homburg-add-codcp/).


The draft was submitted to the ADD WG for discussion and review, but the 
WG chairs and the int area AD considered it work outside the ADD WG 
charter.  However, the WG chairs of ADD and DNSOP and the ADs of both 
WGs regard this draft as relevant work.  Individuals in the IETF also 
showed interest and saw the value of the draft.


The chairs are seeking feedback from the DNSOP WG whether this work can 
be discussed in the WG.  The chairs of the DNS-related WGs see no other 
working group where the draft can be presented, while we prefer to let 
the work go through the IETF process via a WG.



Best regards,

-- Benno




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 115 Call for Agenda Items DNSOP WG

2022-10-17 Thread Benno Overeinder

Dear WG,

This is a Call for Agenda Items for the IETF 115 in London, UK.

DNSOP WG is scheduled on Tuesday, 8 November at 09:30-11:30 (GMT/UTC).

(See for IETF 115 agenda https://datatracker.ietf.org/meeting/115/agenda)


Please email the chairs  with your requests. *Or* 
drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf115 
look for dnsop-ietf115-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 24 October 2022.

See https://datatracker.ietf.org/meeting/important-dates/:
2022-10-24	Monday	Internet Draft submission cut-off (for all drafts, 
including -00) by UTC 23:59 Upload using the ID Submission Tool 
https://datatracker.ietf.org/submit/.



Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] DNSOP WG interim-2022-dnsop-02 meeting agenda (September 26, 2022)

2022-09-12 Thread Benno Overeinder

Hi all,

As mentioned on the mailing list, we have settled on a date for the 
DNSOP WG virtual interim meeting on Monday, September 26, from 15:00 to 
16:00 UTC.


The agenda for the interim is:

* Administrivia
  - Agenda Bashing, Blue Sheets, etc, 5 min

* Current Working Group Business
  - DNS Terminology
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/
Paul Hoffman and Kazunori Fujiwara, 55 min
Chairs Action:

Information about agenda, remote participation and more:
- https://datatracker.ietf.org/doc/agenda-interim-2022-dnsop-02-dnsop-01/
- https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop


Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim week 26-30 September 2022

2022-09-09 Thread Benno Overeinder

Hi all!

We have closed the Doodle poll, thank you for indicating your availability.

The most favourable timeslot has become Monday, September 26, 
15:00-16:00 UTC.


The Meetecho details will be sent to the DNSOP mailing list next week.


Best regards,

Suzanne, Tim and Benno


On 08/09/2022 12:25, Benno Overeinder wrote:

Hi all!

Gentle reminder to fill in the Doodle poll.

We will close the poll today, end-of-business day.

Best,

Suzanne, Tim and Benno

On 31/08/2022 19:56, Benno Overeinder wrote:

Dear DNSOP WG,

We are planning our second DNSOP WG interim meeting for 2022 in the 
week of 26-30 September.


The draft draft-ietf-dnsop-rfc8499bis is on the agenda for the interim 
meeting:

- https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/

Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/e9QDWqBe

The options for the time slots are a compromise for CEST/EDT/PDT/JST.

We will close the Doodle poll at the end of Tuesday 6 September.


Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim week 26-30 September 2022

2022-09-08 Thread Benno Overeinder

Hi all!

Gentle reminder to fill in the Doodle poll.

We will close the poll today, end-of-business day.

Best,

Suzanne, Tim and Benno

On 31/08/2022 19:56, Benno Overeinder wrote:

Dear DNSOP WG,

We are planning our second DNSOP WG interim meeting for 2022 in the week 
of 26-30 September.


The draft draft-ietf-dnsop-rfc8499bis is on the agenda for the interim 
meeting:

- https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/

Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/e9QDWqBe

The options for the time slots are a compromise for CEST/EDT/PDT/JST.

We will close the Doodle poll at the end of Tuesday 6 September.


Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Doodle poll for DNSOP WG interim week 26-30 September 2022

2022-08-31 Thread Benno Overeinder

Dear DNSOP WG,

We are planning our second DNSOP WG interim meeting for 2022 in the week 
of 26-30 September.


The draft draft-ietf-dnsop-rfc8499bis is on the agenda for the interim 
meeting:

- https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/

Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/e9QDWqBe

The options for the time slots are a compromise for CEST/EDT/PDT/JST.

We will close the Doodle poll at the end of Tuesday 6 September.


Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 114 DNSOP WG agenda published

2022-07-25 Thread Benno Overeinder
We made some small changes to the agenda for Thursday, see for the 
latest DNSOP WG agenda https://datatracker.ietf.org/doc/agenda-114-dnsop/.


Best,

-- Suzanne, Tim and Benno


On 21/07/2022 08:18, Benno Overeinder wrote:

All,

An updated agenda has been posted on datatracker, see 
https://datatracker.ietf.org/doc/agenda-114-dnsop/.


Best regards,

-- Suzanne, Tim and Benno


On 12/07/2022 16:29, Benno Overeinder wrote:

All,

The (draft) DNSOP WG agenda for the IETF 114 has been published, see 
https://datatracker.ietf.org/doc/agenda-114-dnsop/.


The agenda now spans the full 2 hours, but if new requests for 
existing WG documents are received, room will be made and "time 
permitting" drafts will be bumped off the agenda.


Reminder, the adoption call of three drafts has been started.  The WG 
is asked to discuss the WG call for adoption on the mailing list, 
whether you consider the document appropriate for adoption, comments 
and feedback.  And please indicate if you are willing to contribute 
text, revise the draft, etc.



Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 114 DNSOP WG agenda published

2022-07-21 Thread Benno Overeinder

All,

An updated agenda has been posted on datatracker, see 
https://datatracker.ietf.org/doc/agenda-114-dnsop/.


Best regards,

-- Suzanne, Tim and Benno


On 12/07/2022 16:29, Benno Overeinder wrote:

All,

The (draft) DNSOP WG agenda for the IETF 114 has been published, see 
https://datatracker.ietf.org/doc/agenda-114-dnsop/.


The agenda now spans the full 2 hours, but if new requests for existing 
WG documents are received, room will be made and "time permitting" 
drafts will be bumped off the agenda.


Reminder, the adoption call of three drafts has been started.  The WG is 
asked to discuss the WG call for adoption on the mailing list, whether 
you consider the document appropriate for adoption, comments and 
feedback.  And please indicate if you are willing to contribute text, 
revise the draft, etc.



Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 114 DNSOP WG agenda published

2022-07-12 Thread Benno Overeinder

All,

The (draft) DNSOP WG agenda for the IETF 114 has been published, see 
https://datatracker.ietf.org/doc/agenda-114-dnsop/.


The agenda now spans the full 2 hours, but if new requests for existing 
WG documents are received, room will be made and "time permitting" 
drafts will be bumped off the agenda.


Reminder, the adoption call of three drafts has been started.  The WG is 
asked to discuss the WG call for adoption on the mailing list, whether 
you consider the document appropriate for adoption, comments and 
feedback.  And please indicate if you are willing to contribute text, 
revise the draft, etc.



Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

2022-07-07 Thread Benno Overeinder

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. Two 
years ago we (as a WG) discussed how to manage the workload of the WG 
and running a poll seemed to be one of the mechanisms to help with that.


Using the search terms "poll" and "survey" individually via the DNSOP 
archive web page, I found the last July email 
(https://mailarchive.ietf.org/arch/msg/dnsop/bXDwmPhft5BXFndKs5xI3FjOewE/) 
which was about prioritization and a bunch of doodle polls about interim 
WG scheduling.  I didn't find any about new work.  For the 
prioritization google thing, I can't actually read the text of the 
google doc via that link, and I'm not sure what to search for in the 
mail archive to find the resultant document if indeed it was published 
to the list.  Searching the archives is *very* clumsy. So, depending 
only on my memory, I seem to remember that other poll was only about 
dealing with accepted work that hadn't progressed (i.e., kill or 
keep).   Scanning forward from the publication date of that poll, I 
can't see anyplace where the result of that poll was actually published 
to the list.  The chair's meeting notes of 6 Aug 2021, 20 Aug 2021 and 3 
Sept 2021 don't reference the poll.  The 19 Nov 2021 notes indicate that 
another poll was being considered for work prioritization, but I can't 
find where it was sent, if at all.


So, could you send me the link to the DNSOP emails where the results of 
the previous two surveys were published please?  And for that matter 
where the second prioritization poll was sent out.


You are correct, we did have one survey/poll.  In my memory they were 
two different surveys, but it was one survey for prioritising existing 
work and open questions about adopting new work.  The results were 
presented in the DNSOP WG chairs slides of the IETF 112 meeting.  The 
new work suggested by the WG was dnssec-bootstrapping and dnssec-automation.


As the notes indicate, we considered starting a poll but ended up not 
doing so for IETF 113.  Thanks for correcting.



Regards,

-- Benno


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

2022-07-07 Thread Benno Overeinder

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 share 
the results of the poll with the WG and how to make an initial 
selection of documents that will be included in the WG call for 
adoption process.  We currently have 6 drafts for which the authors 
have asked WG adoption, but that is too much new work for the WG to 
work on.


Any feedback on improving the process to prioritise work in the WG is 
welcome.


All of that is a good and just reason to send out calls for adoption. 
But the point of the previous messages was that the poll was not the way 
to do that.  Basically, making a poll choice without providing context 
and an opportunity for discussion a) lacks transparency (in that when 
the chairs make a decision, the WG has no basis on which to evaluate 
that decision), b) lacks nuance (in that the choices provided do not 
cover some shadings of what to do - e.g., not ready for consideration), 
c) lacks WG participation (a discussion about a document gets us to a 
better result than blind voting).


I see the points you are making but as we mentioned we will be sharing 
and discussing the results of the poll, so for transparency of the 
decision making process and WG participation in this it will be on the 
WG mailing list.  For your concerns wrt. the nuance there should be room 
during this mailing list discussion.


If I read your concerns correctly, instead of 6 WG call for adoptions in 
a short period (or in one go) we will have a phased WG call for 
adoptions in the next month with 3 candidates and when the WG completes 
current existing work, another batch of 2, 3 or 4 WG calls for adoption 
will be issued.  And an outcome of the call for adoption can be a 
yes/no/not ready for consideration/..., as usual.


Conducting a survey (2 times now) has worked well over the past 1.5 
years to prioritise finishing existing work and starting new work.  Two 
years ago we (as a WG) discussed how to manage the workload of the WG 
and running a poll seemed to be one of the mechanisms to help with that.


The fact that the chairs did not respond to the original messages is 
also a bit problematic.


Apologies for not responding to the original messages, but was in no way 
intended to ignore them.


Regards,

-- Benno


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

2022-07-07 Thread Benno Overeinder

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 original announcement, and it's thus unclear how the poll results will be 
acted on.


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 share 
the results of the poll with the WG and how to make an initial selection 
of documents that will be included in the WG call for adoption process. 
 We currently have 6 drafts for which the authors have asked WG 
adoption, but that is too much new work for the WG to work on.


Any feedback on improving the process to prioritise work in the WG is 
welcome.


Best,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] 2nd IETF 114 Call for Agenda Items DNSOP WG

2022-07-07 Thread Benno Overeinder

Dear WG,

This is the second Call for Agenda Items for the IETF 114, 23-29 July in 
Philadelphia.


DNSOP WG is scheduled on Thursday, 28 July at 13:30-15:30 (EDT/UTC-4).

(See for IETF 114 agenda https://datatracker.ietf.org/meeting/agenda/)

Please email the chairs  with your requests. 
*Or* drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf114 
look for dnsop-ietf114-agenda-requests.md.


We have already received a number of agenda time requests, but there is 
still room for 2 or 3 presentation slots.


Please Note: Draft Submission Deadline is Monday 11 July 2022.

See https://datatracker.ietf.org/meeting/important-dates/:
2022-07-11 (Monday): Internet Draft submission cut-off (for all drafts, 
including -00) by UTC 23:59.  Upload using the ID Submission Tool 
https://datatracker.ietf.org/submit/.


Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] DNSOP Document Adoption Poll (June 2022)

2022-07-07 Thread Benno Overeinder

Hi all,

Gentle reminder, the poll runs until July 9.

Best,

-- Benno


On 27/06/2022 12:44, Tim Wicinski wrote:


All

We have six documents that have requested adoption from the working 
group. My opinion is that we send out adoption calls for all of these 
and let the working group sort it out, but was told that is just crazy. 
Since Warren loves these poll things, we put another one together on all 
the documents in question.



https://forms.gle/TVKeokYvnU55eq2x7


We'll run this poll for two weeks and end on the 9th of July. However, 
we have a chai9rs call on the 5th of July and I'm confident we'll have 
an obvious clear set of documents to begin adoption calls on.


thanks
tim




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 114 Call for Agenda Items DNSOP WG

2022-06-24 Thread Benno Overeinder

On 24/06/2022 12:19, Benno Overeinder wrote:

DNSOP has two sessions requested for the IETF 114:


One session requested, not two.


     dnsop Session 1 (2:00 requested)


-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 114 Call for Agenda Items DNSOP WG

2022-06-24 Thread Benno Overeinder

Dear WG,

This is a Call for Agenda Items for the IETF 114, 23-29 July in 
Philadelphia.


DNSOP has two sessions requested for the IETF 114:

dnsop Session 1 (2:00 requested)

(The preliminary IETF 114 agenda will be published later today on 24 
June 2022.)


Please email the chairs  with your requests. *Or* 
drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf114 
look for dnsop-ietf114-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 11 July 2022.

See https://datatracker.ietf.org/meeting/important-dates/:
2022-07-11 (Monday): Internet Draft submission cut-off (for all drafts, 
including -00) by UTC 23:59.  Upload using the ID Submission Tool 
https://datatracker.ietf.org/submit/.


Thanks,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2022-05-24

2022-05-23 Thread Benno Overeinder

Dear all,

This is a gentle reminder to the WG that the interim meeting is 
scheduled for tomorrow, 24 May 2022, 17:00-18:00 UTC.


Regards,

Suzanne, Tim and Benno


On 14/05/2022 12:10, Benno Overeinder wrote:

Dear all,

All information for the interim meeting (agenda, drafts and the slides 
if they are available) can be found here: 
https://datatracker.ietf.org/meeting/interim-2022-dnsop-01/session/dnsop


Regards,

Suzanne, Tim and Benno


On 13/05/2022 19:55, IESG Secretary wrote:

The Domain Name System Operations (dnsop) WG will hold
a virtual interim meeting on 2022-05-24 from 19:00 to 20:00 
Europe/Amsterdam (17:00 to 18:00 UTC).


Agenda:
Agenda

* Chairs, Administrivia (10 min)

* Ulrich Wisser and Shumon Huque, DNSSEC Automation (25 min)
   https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/

* Peter Thomassen and Nils Wisiol, Automatic DNSSEC Bootstrapping 
using Authenticated Signals from the Zone's Operator (25 min)
   
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/



Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=45d75893-b015-4b13-b835-204c9de2b003 



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2022-05-24

2022-05-14 Thread Benno Overeinder

Dear all,

All information for the interim meeting (agenda, drafts and the slides 
if they are available) can be found here: 
https://datatracker.ietf.org/meeting/interim-2022-dnsop-01/session/dnsop


Regards,

Suzanne, Tim and Benno


On 13/05/2022 19:55, IESG Secretary wrote:

The Domain Name System Operations (dnsop) WG will hold
a virtual interim meeting on 2022-05-24 from 19:00 to 20:00 Europe/Amsterdam 
(17:00 to 18:00 UTC).

Agenda:
Agenda

* Chairs, Administrivia (10 min)

* Ulrich Wisser and Shumon Huque, DNSSEC Automation (25 min)
   https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/

* Peter Thomassen and Nils Wisiol, Automatic DNSSEC Bootstrapping using 
Authenticated Signals from the Zone's Operator (25 min)
   https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
  



Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=45d75893-b015-4b13-b835-204c9de2b003

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim on 24 or 25 May

2022-05-13 Thread Benno Overeinder

All,

The Doodle poll is closed and we have selected:

Tuesday May 24, 17:00-18:00 UTC

The details and agenda of the interim meeting will be shared in a 
separate email.


-- Benno


On 10/05/2022 00:08, Benno Overeinder wrote:

Hi all,

The following newly adopted DNSOP WG drafts are on the agenda for the 
interim meeting:


- dnssec-automation, Ulrich Wisser and Shumon Huque
- dnssec-bootstrapping, Peter Thomassen and Nils Wisiol

We want to close the Doodle poll at the end of Wednesday, 11 May.

Best regards,

Suzanne, Tim and Benno


On 29/04/2022 23:04, Benno Overeinder wrote:

Dear DNSOP WG,

We are planning our first DNSOP WG interim meeting for 2022 on May 24 
or 25.


The DNSOP WG chairs are contacting the authors of two drafts that can 
be put on the agenda.  Details to follow.


Please fill in the Doodle poll to settle on a day and time:
- https://doodle.com/meeting/participate/id/e0RyVkXb

The options for the time slots are CEST/EDT/PDT friendly.

We will close the Doodle poll at the end of Thursday, 5 May.

Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim on 24 or 25 May

2022-05-09 Thread Benno Overeinder

Hi all,

The following newly adopted DNSOP WG drafts are on the agenda for the 
interim meeting:


- dnssec-automation, Ulrich Wisser and Shumon Huque
- dnssec-bootstrapping, Peter Thomassen and Nils Wisiol

We want to close the Doodle poll at the end of Wednesday, 11 May.

Best regards,

Suzanne, Tim and Benno


On 29/04/2022 23:04, Benno Overeinder wrote:

Dear DNSOP WG,

We are planning our first DNSOP WG interim meeting for 2022 on May 24 or 
25.


The DNSOP WG chairs are contacting the authors of two drafts that can be 
put on the agenda.  Details to follow.


Please fill in the Doodle poll to settle on a day and time:
- https://doodle.com/meeting/participate/id/e0RyVkXb

The options for the time slots are CEST/EDT/PDT friendly.

We will close the Doodle poll at the end of Thursday, 5 May.

Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Doodle poll for DNSOP WG interim on 24 or 25 May

2022-04-29 Thread Benno Overeinder

Dear DNSOP WG,

We are planning our first DNSOP WG interim meeting for 2022 on May 24 or 25.

The DNSOP WG chairs are contacting the authors of two drafts that can be 
put on the agenda.  Details to follow.


Please fill in the Doodle poll to settle on a day and time:
- https://doodle.com/meeting/participate/id/e0RyVkXb

The options for the time slots are CEST/EDT/PDT friendly.

We will close the Doodle poll at the end of Thursday, 5 May.

Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Benno Overeinder

Mukund,

On 29/04/2022 22:27, Mukund Sivaraman wrote:


This is indeed how the DNSOP chairs see it and have guided the (new set of)
authors in this way.  We have also asked Haisheng to contact the secretariat
to correct the situation as we cannot withdraw individual drafts or change
status.


With the way this is worded, is it accepted practice for the names of
authors of a document to be removed to make way for another set of
authors?


No, certainly not.  If you interpret it that way, I have chosen the 
wrong words.


What I meant to say is that we made suggestions or try to guide the 
practical procedure for changing the status of document to indicate that 
it is not an active document.


The broader discussion of whether it is an accepted practice or not was 
not the subject of my answer to the list.  As I understand there is a 
discussion in the IESG now, and with the email thread on the list and 
Brian's draft, 
https://datatracker.ietf.org/doc/html/draft-carpenter-whats-an-author-02, we 
can make progress to better define the process and provide guidance to 
authors and IETF participants.



-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

2022-04-29 Thread Benno Overeinder

Hi Lars, WG,

On 29/04/2022 12:54, Lars Eggert wrote:

On 2022-4-29, at 0:30, Cindy Morgan  wrote:

The rest of this is a bit of a tangle, and I've referred it to the IESG for 
further guidance on what steps the Secretariat should take next.


the IESG is reviewing what has happened.

(My personal first impression is that this might be a case where a contributor 
intended to revive an expired document by a different set of authors, and was 
unsure how to best go about this.)


This is indeed how the DNSOP chairs see it and have guided the (new set 
of) authors in this way.  We have also asked Haisheng to contact the 
secretariat to correct the situation as we cannot withdraw individual 
drafts or change status.



Regards,

--  Benno
DNSOP co-chair

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation

2022-04-17 Thread Benno Overeinder

Hi all,

Thank you for your feedback and willingness to contribute text or review 
the document in the working group.


The Call for Adoption has ended and with good support from the WG, the 
document is adopted as a WG Internet-Draft.


The chairs will ask the authors to resubmit the document with the name 
draft-ietf-dnsop-dnssec-automation.


Thanks,

Suzanne, Tim and Benno


On 25/03/2022 16:35, Benno Overeinder wrote:
As with the previous Call for Adoption today, at this week's DNSOP 
meeting at IETF 113, we announced that we are initiating a Call for 
Adoption for the draft-wisser-dnssec-automation.  With the survey we 
conducted for the last IETF 112, this draft was also a clear candidate.


With this email we start a period of two weeks for the call for adoption 
of draft-wisser-dnssec-automation on the mailing list.


The draft is available here: 
https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/.


Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 8 April 2022

Thanks,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping

2022-04-17 Thread Benno Overeinder

Hi all,

Thank you for your feedback and willingness to contribute text or review 
the document in the working group.


The Call for Adoption has ended and with good support from the WG, the 
document is adopted as a WG Internet-Draft.


The chairs will ask the authors to resubmit the document with the name 
draft-ietf-dnsop-dnssec-bootstrapping.


Thanks,

-- Benno


On 25/03/2022 16:27, Benno Overeinder wrote:
As announced during the DNSOP meeting this week at the IETF 113, we are 
starting a Call for Adoption for the 
draft-thomassen-dnsop-dnssec-bootstrapping.  With the survey we 
conducted before the last IETF 112, this draft was a clear candidate.


With this email we start a period of two weeks for the call for adoption 
of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list.


The draft is available here: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ 



Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 8 April 2022

Thanks,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Call for Adoption: draft-wisser-dnssec-automation

2022-03-25 Thread Benno Overeinder
As with the previous Call for Adoption today, at this week's DNSOP 
meeting at IETF 113, we announced that we are initiating a Call for 
Adoption for the draft-wisser-dnssec-automation.  With the survey we 
conducted for the last IETF 112, this draft was also a clear candidate.


With this email we start a period of two weeks for the call for adoption 
of draft-wisser-dnssec-automation on the mailing list.


The draft is available here: 
https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/.


Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 8 April 2022

Thanks,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping

2022-03-25 Thread Benno Overeinder
As announced during the DNSOP meeting this week at the IETF 113, we are 
starting a Call for Adoption for the 
draft-thomassen-dnsop-dnssec-bootstrapping.  With the survey we 
conducted before the last IETF 112, this draft was a clear candidate.


With this email we start a period of two weeks for the call for adoption 
of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list.


The draft is available here: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/


Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 8 April 2022

Thanks,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Fwd: [Add] Joint ADD-DPRIVE-DNSOPS January 26, 2022 Interim

2022-01-19 Thread Benno Overeinder

Hi all,

As previously announced, there will be a joint ADD-DPRIVE-DNSOP interim 
meeting next Wednesday, January 26.  Below is the forwarded email from 
the ADD mailing list.  Note: the date is Wednesday, January 26.


Best regards,

Suzanne, Tim and Benno


 Forwarded Message 
Subject:[Add] Joint ADD-DPRIVE-DNSOPS January 27, 2022 Interim
Date:   Mon, 10 Jan 2022 19:42:04 +
From:   Deen, Glenn 
To: a...@ietf.org 



Hi everyone,

The chairs of ADD, DPRIVE, and DNSOPS have scheduled a joint interim on 
the topic of Split-DNS for January 27, 2022 from 1700-1830 UTC.


This was originally announced on the ADD list back on Dec 20, but didn’t 
get a lot of attention like due to the holidays at the time 
(https://mailarchive.ietf.org/arch/msg/add/Jd3Tql9dLkYEBWrv5ifsMAU7M9g/ 
)


Background:

---

This is a follow up to the discussion that has taken place in ADD around 
how to support discovery of encrypted DNS resolvers in Split-DNS 
environments.   That extended discussion in ADD current stands at:  (1) 
The ADD group showed that there was consensus that the problem of how to 
do discovery in Split-DNS environments was important for the group to 
work on;  (2) The ADD group currently does not have consensus on how it 
should be done.  (3) A number of discussion issues that are outside of 
the ADD Charter have been raised around requirements that can uniquely 
occur in split-DNS environments.


It is the intent to use this joint session to discuss such issues, and 
others as needed to better understand the requirements that need to be 
satisfied for a ADD discovery mechanism for Split-DNS environments.


Motivation:

--

  * Split-DNS is widely used in Enterprise and Intuitional network
operations and in VPN environments.
  * Without a practical and acceptable standard on how to discover
encrypted DNS resolvers it is likely that operators that make use of
split-DNS will take it upon themselves to invent and deploy a wide
variety of non-standardized discovery methods.   This will hamper
any future standards that may be developed, and will impact users
negatively since they will not have a standard discovery mechanism
to make use of.
  * The hope is that by discussing the security, privacy, and
operational needs of discovery in Split-DNS environments that the
ADD group can make progress toward documenting how to do it in a
standard way

Purpose of the Joint Interim:

--

  * To discuss the issues around discovery of encrypted DNS resolvers in
a  Split-DNS environment.

What this Interim is NOT:

---

  * This is not intended as a referendum on the use of split-DNS.
  * This is not a workshop on how proposals of how to end the practice
of Split-DNS or how to re-engineer networks that have it currently
deployed.

Agenda

---

  * Agenda and any Materials will be posted at:
https://datatracker.ietf.org/meeting/interim-2022-add-01/session/add

  * The chairs of the 3 groups are working on the agenda for the Interim
and plan on making it available well ahead of the 1-27-2022 Interim
Meeting.
Thanks,

Glenn Deen on behalf of the ADD, DPrive, DNSOPS co-chairs
-- 
Add mailing list
a...@ietf.org
https://www.ietf.org/mailman/listinfo/add

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Fwd: Adaptive DNS Discovery (add) WG Virtual Meeting: 2022-01-26

2021-12-21 Thread Benno Overeinder
The ADD, DNSOP and DPRIVE working groups are planning a joint interim 
meeting.


Details will follow, but you can already mark the date in your agenda.


Best regards,

Suzanne, Tim and Benno


 Forwarded Message 
Subject: Adaptive DNS Discovery (add) WG Virtual Meeting: 2022-01-26
Date: Mon, 20 Dec 2021 13:28:12 -0800
From: IESG Secretary 
To: IETF-Announce 
CC: a...@ietf.org

The Adaptive DNS Discovery (add) WG will hold
a virtual interim meeting on 2022-01-26 from 09:00 to 10:30 
America/Los_Angeles (17:00 to 18:30 UTC).


Agenda:
To follow

Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=e5378ab2-8290-469a-801f-bf71d754ac20

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] DNSOP WG interim-2021-dnsop-03 meeting agenda (December 15, 2021)

2021-12-10 Thread Benno Overeinder
As previously announced, the DNSOP WG will hold a virtual interim 
meeting on Wednesday, December 15 from 17:00 to 18:00 UTC.


We have an updated agenda:

* DNS Terminology, 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ (30 mins)


* Delegation Revalidation by DNS Resolvers, 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/ (25 mins)


Information about agenda, remote participation and more:
https://datatracker.ietf.org/doc/agenda-interim-2021-dnsop-03-dnsop-01/


Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim in December 2021

2021-12-02 Thread Benno Overeinder

Hi,

The selection has been made.  Virtually all participants can attend the 
DNSOP interim meeting on December 15, 17:00-18:00 UTC.


I will make the reservations in datatracker and Meetecho, and forward 
the details to the mailing list.



Best regards,

-- Benno


On 29/11/2021 12:35, Benno Overeinder wrote:

Hi all,

Don't forget to fill in the Doodle before the end of Wednesday, 1 December.

Thanks!


On 23/11/2021 23:03, Benno Overeinder wrote:

Dear DNSOP WG,

We are planning our third DNSOP WG interim meeting in December, in 
week 49 or week 50.


The draft DNS Terminology is the main topic on the agenda for the 
interim meeting:

- https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/

Please fill in the Doodle poll to settle on a day and time:
- 
https://doodle.com/poll/wt45258fyhw7ppst?utm_source=poll_medium=link


The options for the time slots are PST friendly.

We will close the Doodle poll at the end of Wednesday, 1 December.


Best regards,


Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim in December 2021

2021-11-29 Thread Benno Overeinder

Hi all,

Don't forget to fill in the Doodle before the end of Wednesday, 1 December.

Thanks!


On 23/11/2021 23:03, Benno Overeinder wrote:

Dear DNSOP WG,

We are planning our third DNSOP WG interim meeting in December, in week 
49 or week 50.


The draft DNS Terminology is the main topic on the agenda for the 
interim meeting:

- https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/

Please fill in the Doodle poll to settle on a day and time:
- https://doodle.com/poll/wt45258fyhw7ppst?utm_source=poll_medium=link

The options for the time slots are PST friendly.

We will close the Doodle poll at the end of Wednesday, 1 December.


Best regards,


Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Doodle poll for DNSOP WG interim in December 2021

2021-11-23 Thread Benno Overeinder

Dear DNSOP WG,

We are planning our third DNSOP WG interim meeting in December, in week 
49 or week 50.


The draft DNS Terminology is the main topic on the agenda for the 
interim meeting:

- https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/

Please fill in the Doodle poll to settle on a day and time:
- https://doodle.com/poll/wt45258fyhw7ppst?utm_source=poll_medium=link

The options for the time slots are PST friendly.

We will close the Doodle poll at the end of Wednesday, 1 December.


Best regards,


Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 112 DNSOP WG agenda

2021-11-12 Thread Benno Overeinder

Dear WG,

We updated the agenda for Session II today.

After the presentation of nsec3 iterations guidance, there was quite a 
bit of relevant discussion in the jabber room.  It seemed like a good 
idea to set aside 15 minutes for today's session to continue the 
discussion, and luckily Wes agreed.


https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-03

Best regards,

Suzanne, Tim and Benno


On 09/11/2021 17:37, Benno Overeinder wrote:
An updated agenda for DNSOP has been published.  We had to swap some 
presentations due to the availability of presenters.


https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-01


Best regards

Suzanne, Tim and Benno


On 03/11/2021 22:37, Benno Overeinder wrote:

All,

The DNSOP WG agenda for IETF 112 has been published, see 
https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-00.


Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 112 DNSOP WG agenda

2021-11-09 Thread Benno Overeinder
An updated agenda for DNSOP has been published.  We had to swap some 
presentations due to the availability of presenters.


https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-01


Best regards

Suzanne, Tim and Benno


On 03/11/2021 22:37, Benno Overeinder wrote:

All,

The DNSOP WG agenda for IETF 112 has been published, see 
https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-00.


Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] nsec3-parameters opinions gathered

2021-11-05 Thread Benno Overeinder

Wes,

On 05/11/2021 09:40, Vladimír Čunát wrote:

On 04/11/2021 23.44, Wes Hardaker wrote:

The most important sticking point is there are 4 implementations (thank
you for the links Matthijs) that have implemented 150.  Since DNSOP
strives for implementations of specs, I think this is the number we
should publish*unless the vendors speak up and say they'll drive lower*.


I'm convinced that 150 was just a quick stop-gap compromise and that 
from the start vendors expected that dnsop might set it lower later. 
Therefore I don't think this *argument* for keeping 150 is really valid.


As for Knot Resolver, I see no problem in setting the hard limit lower, 
especially if that gets published in this RFC.  From Viktor I gather 
that 100 shouldn't cause issues even at this moment, especially if it's 
only a limit for downgrading to insecure (which won't be even noticed by 
most DNS consumers).  So personally I expected the draft to lower the 
bound to <=100, though as I said... for us the *overall* performance 
ratio from e.g. 150 -> 50 isn't that large.


For Unbound, we have no problem setting the iteration cap to a value 
lower than the current 150.  If Viktor's analysis shows a limit of 100 
is feasible without (m)any problems for operators, and this value will 
be adopted in the soon-to-be-released RFC, we will use the new limit value.



Cheers,

-- Benno


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 112 DNSOP WG agenda

2021-11-03 Thread Benno Overeinder

All,

The DNSOP WG agenda for IETF 112 has been published, see 
https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-00.


Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Fwd: Domain Name System Operations (dnsop) WG Virtual Meeting: 2021-10-26

2021-10-26 Thread Benno Overeinder

Late reminder for the DNSOP interim meeting this afternoon (in 2 minutes).

-- Benno


 Forwarded Message 
Subject: [DNSOP] Domain Name System Operations (dnsop) WG Virtual 
Meeting: 2021-10-26

Date: Fri, 15 Oct 2021 15:39:40 -0700
From: IESG Secretary 
To: IETF-Announce 
CC: dnsop@ietf.org

The Domain Name System Operations (dnsop) WG will hold
a virtual interim meeting on 2021-10-26 from 14:00 to 15:00 UTC.

Agenda:
# DNS Operations (DNSOP) Working Group
## interim-2021-dnsop-02


### 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](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md)

* [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/)

* [Propose 
Slides](https://datatracker.ietf.org/meeting/interim-2021-dnsop-02/session/dnsop)


## Session interim-2021-dnsop-02

* Date: 26 October 2021
* Time: 14:00-15:00 UTC
* MeetEcho: 
[https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4](https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4)


* Jabber:  [dn...@jabber.ietf.org](dn...@jabber.ietf.org)
* Minutes: 
[https://codimd.ietf.org/notes-ietf-interim-2021-dnsop-02-dnsop](https://codimd.ietf.org/notes-ietf-interim-2021-dnsop-02-dnsop)



## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  5 min

### Current Working Group Business

*   DNS Error Reporting
- 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

- Roy Arends , 50 min
- Chairs Action:

Topics
1. Introduction: state of the I-D
2. Dependency on RFC8914 (Extended DNS Errors): State of 
implementation of EDE in various implementation

3. Issues and potential solutions
- encapsulation of the erroneous domain
- signalling EDE support


Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] IETF 112 Call for Agenda Items DNSOP WG

2021-10-19 Thread Benno Overeinder

Dear WG,

This is a Call for Agenda Items for the IETF 112, from 6-12 November 2021.

The DNSOP WG sessions at IETF 112 are scheduled at (times are CET/UTC+1):

dnsop Session 1
Thursday, 11 November 2021, Session III 1600-1800
Room Name: Room 3 size: 503
-
dnsop Session 2
Friday, 12 November 2021, Session II 1430-1530
Room Name: Room 4 size: 504
-

iCalendar: https://datatracker.ietf.org/meeting/112/sessions/dnsop.ics


Please email the chairs  with your requests. 
*Or* drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf112 
look for dnsop-ietf112-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 25 October 2021.

See https://datatracker.ietf.org/meeting/important-dates/:
* 2021-10-25 (Monday): Internet Draft submission cut-off (for all 
drafts, including -00) by UTC 23:59.  Upload using the ID Submission 
Tool https://datatracker.ietf.org/submit/.


Best,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim week 25-29 October 2021

2021-10-15 Thread Benno Overeinder

All,

We closed the Doodle poll and selected the time slot Tuesday, October 
26, 14:00-15:00 UTC.  Not in absolute numbers the winner, but all 
implementers can only participate in that time slot.


The next step is to share the agenda and schedule the DNSOP interim in 
datatracker.


Best,

-- Benno


On 11/10/2021 17:45, Benno Overeinder wrote:

Dear DNSOP WG,

We are planning our second DNSOP WG interim meeting in the week of 25-29 
October.


The draft dns-error-reporting is on the agenda for the interim meeting:
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/poll/nandts5k295y6i6q?utm_source=poll_medium=link

We will close the Doodle poll at the end of Thursday 14 October.


Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Doodle poll for DNSOP WG interim week 25-29 October 2021

2021-10-11 Thread Benno Overeinder

Dear DNSOP WG,

We are planning our second DNSOP WG interim meeting in the week of 25-29 
October.


The draft dns-error-reporting is on the agenda for the interim meeting:
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/poll/nandts5k295y6i6q?utm_source=poll_medium=link

We will close the Doodle poll at the end of Thursday 14 October.


Best regards,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Question on interpretation of DO and CD

2021-10-11 Thread Benno Overeinder

On 07/10/2021 08:52, Mark Andrews wrote:

DNSSEC will work reasonably well if the upstream are just DNSSEC aware (keep the
RRSIGs with the data they cover, pass through negative proofs required for
the answers) if there is not spoofed traffic, a mix of DNSSEC aware and DNSSEC
oblivious server for the zone, etc.  A validating upstream will block this
badness and only pass through good responses. A non-validating upstream will
cache this garbage.

It will fail abysmally if the upstreams are not DNSSEC aware.  Don’t even
attempt it.


With the getdns API library and stub resolver design, quite a bit of 
effort has gone into "road block avoidance" i.e. checking if the 
upstream resolver is DNSSEC aware and falling back to full recursion if 
it isn't (to obtain the DNSSEC data for end-point validation).


For pictures, see the slide desk 
https://getdnsapi.net/slides/an-earnest-stub.pdf, slide 17 and onwards.



-- Benno

--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] planning and call for presentations DNSOP interim in October (in 3rd or 4th week)

2021-10-01 Thread Benno Overeinder

Hi all,

The interim in September was very helpful in making progress on the 
drafts avoid-fragmentation and glue-is-not-optional.


The DNSOP chairs are planning another interim in October, preferably the 
3rd week of October (18-22 October).  We will send a Doodle for 
selecting day & time later.


We would like to ask authors of drafts to contact us 
 to indicate that they would like to present and 
discuss their draft.  Otherwise, the chairs have suggestions and will 
contact authors.


Thanks!

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] REMINDER: DNSOP Interim 2021-09-15 01:00 - 02:00 UTC

2021-09-14 Thread Benno Overeinder

Hi all,

The Meetecho URL for the interim meeting is:
https://meetings.conf.meetecho.com/interim/?short=a910f22a-d46b-401f-be04-97c290437214

All material (agenda, slides, etc.) for the interim meeting can be found 
here:

https://datatracker.ietf.org/meeting/interim-2021-dnsop-01/session/dnsop

Best,

-- Benno

On 14/09/2021 02:31, Tim Wicinski wrote:

All

A Reminder that there is an upcoming DNSOP Interim meeting.
This will be happening at 2021-09-15 01:00 - 02:00 UTC.
Please adjust for your local time zone.

The Meetecho URL is:
https://meetings.conf.meetecho.com/interim/?short=a910f22a-d46b-401f-be04-97c290437 
214


Two items for discussion:

* dnsop-avoid-fragmentation
* dnsop-glue-is-not-optional

Thanks, and hopefully folks can make it.

tim



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Fwd: IAB Seeks Feedback on Candidate for ICANN NomCom; Nominations remain open

2021-09-01 Thread Benno Overeinder

Hi,

This is also relevant to our WG, so forwarding the call for nominations 
for the ICANN NomCom to the WG mailing list.


As you can read below, one candidate has accepted a nomination, but the 
IAB extended the call for nomination during the feedback period.


Please consider nominating yourself as a candidate for the ICANN NomCom. 
 For more information, read the emails on ietf-announce referenced 
below ([1] and [2]).



Best,

-- Benno


 Forwarded Message 
Subject: IAB Seeks Feedback on Candidate for ICANN NomCom; Nominations 
remain open

Date: Thu, 26 Aug 2021 12:06:22 -0700
From: IAB Executive Administrative Manager 
Reply-To: ex...@iab.org, iab-ch...@iab.org
To: IETF Announcement List 

As previously announced [1], the IAB (on behalf of the IETF) has been 
asked to supply a member to the 2022 ICANN Nominating Committee (NomCom) 
by mid-September 2021. After extending the call for nominations [2], one 
candidate has accepted a nomination:


- Vittorio Bertola

The IAB solicits feedback on this candidate by 23:59 UTC on Thursday, 
2021-09-09. Please send  your responses to iab-ch...@iab.org and 
ex...@iab.org. If you would like your feedback to be anonymized, please 
indicate such in your response.
The IAB desires to have a diverse pool of candidates for the 
appointments it makes. Since there is currently only a single candidate 
for this appointment, the IAB will continue to accept nominations during 
the feedback period. The names of any additional candidates that are put 
forward will also be sent to the community for feedback.


On behalf of the IAB,
Cindy Morgan
IAB Executive Administrative Manager

[1] 
https://mailarchive.ietf.org/arch/msg/ietf-announce/o-q6AfhJmXAqulmuR-As4alE_wM/


[2] 
https://mailarchive.ietf.org/arch/msg/ietf-announce/6Snsx5OqRUqYTxhxTI0KvZqglpo/


___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim week 13-17 September 2021

2021-09-01 Thread Benno Overeinder

Thank you for filling in the doodle.

There were several options with a similar number of votes, but the 
US/Pacific time zone/participation was the tie breaker.


The DNSOP interim meeting will be scheduled on Wed 15 September, 
1:00-2:00 AM UTC.


Best,

-- Benno


On 29/08/2021 15:39, Benno Overeinder wrote:
Gentle reminder to the WG to fill in the doodle before the end of Monday 
(30 August).


Thanks,

-- Benno


On 25/08/2021 13:53, Benno Overeinder wrote:

Dear DNSOP WG,

We are scheduling a DNSOP WG interim meeting in the week of 13-17 
September.


The following drafts are on the agenda:
* dnsop-avoid-fragmentation
* dnsop-glue-is-not-optional

To select a date and time slot, we created a doodle poll.  The authors 
of the drafts are in the US and Japan time zone, so the time slots 
available take this into account.


https://doodle.com/poll/4gfit23w3ixrmgh8?utm_source=poll_medium=link

Please fill in the doodle before the end of Monday (30 August).

Thank you,

Suzanne, Tim and Benno


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Doodle poll for DNSOP WG interim week 13-17 September 2021

2021-08-29 Thread Benno Overeinder
Gentle reminder to the WG to fill in the doodle before the end of Monday 
(30 August).


Thanks,

-- Benno


On 25/08/2021 13:53, Benno Overeinder wrote:

Dear DNSOP WG,

We are scheduling a DNSOP WG interim meeting in the week of 13-17 
September.


The following drafts are on the agenda:
* dnsop-avoid-fragmentation
* dnsop-glue-is-not-optional

To select a date and time slot, we created a doodle poll.  The authors 
of the drafts are in the US and Japan time zone, so the time slots 
available take this into account.


https://doodle.com/poll/4gfit23w3ixrmgh8?utm_source=poll_medium=link

Please fill in the doodle before the end of Monday (30 August).

Thank you,

Suzanne, Tim and Benno


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Doodle poll for DNSOP WG interim week 13-17 September 2021

2021-08-25 Thread Benno Overeinder

Dear DNSOP WG,

We are scheduling a DNSOP WG interim meeting in the week of 13-17 
September.


The following drafts are on the agenda:
* dnsop-avoid-fragmentation
* dnsop-glue-is-not-optional

To select a date and time slot, we created a doodle poll.  The authors 
of the drafts are in the US and Japan time zone, so the time slots 
available take this into account.


https://doodle.com/poll/4gfit23w3ixrmgh8?utm_source=poll_medium=link

Please fill in the doodle before the end of Monday (30 August).

Thank you,

Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Moving WG documents forward

2021-07-31 Thread Benno Overeinder

On 31/07/2021 18:38, Paul Hoffman wrote:

On Jul 31, 2021, at 4:45 AM, Benno Overeinder  wrote:

For the individual drafts, the DNSOP chairs will contact the authors and 
discuss the way forward with the WG.


During the meeting, there was a call for more transparency, and co-chair Tim 
strongly agreed with it.

Please strongly consider reversing those two steps: discuss the way forward 
with the WG, *then* contact the authors (who should be following the WG 
anyway...). In the unlikely-but-possible case where the WG wants to move 
forward on a draft and none of the current authors want to do so, the chairs 
can ask the list for new volunteer editors.



Agree that the WG determines what happens to a document and that is 
discussed by the WG, that is clear. It was merely a sign of courtesy to 
contact the authors of the document first to let them know that it will 
be discussed.



-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

2021-07-31 Thread Benno Overeinder

Hi Paul, Working Group,

On 30/07/2021 20:43, Paul Wouters wrote:


So was draft-ietf-dnsop-delegation-only until it was killed yesterday due to 
lack of time because we had to spend it on political discussions with ISO 
liaisons.


To be clear, the discussion of the poll and priorities was informative 
and no decisions have been made about dropping WG documents yet.  Your 
argument that the document got delayed due to other more pressing drafts 
is acknowledged.


We also hold off the suggestion to raise hands for alt-tld draft in a 
similar way.  The poll helped the discussion, but is only part of the 
discussion.  For the individual drafts, the DNSOP chairs will contact 
the authors and discuss the way forward with the WG.



Best regards,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated

2021-07-29 Thread Benno Overeinder
As a follow up to Shumon's email, the order is indeed different than 
usual.  Normally we schedule current business first, but for 
agenda-technical reasons (allowing discussion) we have changed the order.


Hope you understand the exception to the rule.

Best,

-- Benno


On 29/07/2021 21:04, Shumon Huque wrote:
On Thu, Jul 29, 2021 at 2:49 PM Shumon Huque > wrote:


On Thu, Jul 29, 2021 at 2:41 PM Peter van Dijk
mailto:peter.van.d...@powerdns.com>>
wrote:


This is not a comment on the specific draft at all. This is a
comment
on WG process. It seems weird to me to discuss prioritisation
-after-
we spend time talking about current and, especially, new business.


I'm sure the chairs will answer you on process, but I wanted to
state that I
had actually posted -00 before the draft cutoff (-01 posted later
was a minor
tweak) and asked for agenda time then. The chairs apologized to me
later
that they hadn't responded earlier and said they could fit me on
Thursday.


Quick followup - I'm happy to go at the end. I'm not even sure I was 
going to

ask for adoption - this was more information sharing, and asking the WG what
I should do with this draft. So it need not impact the current work 
prioritization
discussion. (I am assuming the WG will not bless the BL method, so it is 
unlikely

to adopt it or a derivative, but I may be surprised).

Shumon.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


  1   2   >