[DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-rfc7816bis-11: (with COMMENT)

2021-09-01 Thread Éric Vyncke via Datatracker 
Éric Vyncke has entered the following ballot position for
draft-ietf-dnsop-rfc7816bis-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/



--
COMMENT:
--

Thank you for the work put into this document. A simple but efficient technique.

Thank you also for addressing completely my previous blocking DISCUSS. It is
now cleared.

Special thanks to Tim Wicinski for his shepherd's write-up notably about the WG
consensus.

I hope that this helps to improve the document,

Regards,

-éric

== PREVIOUS DISCUSS (no more valid) ==

-- Section 2.1 --
I support Erik Kline's COMMENT on this and am raising it to a blocking DISCUSS.

A/ in all the discussion in the last §, a  would have the same benefit when
compared to a NS QTYPE. Or what did I miss ?

B/ the last two sentences "Another potential benefit...happy eyeballs query for
the A QTYPE." are puzzling as using A QTYPE will actually only cache the A
answer for the minimized request and more and more Internet users are using
IPv6 nowadays (and possibly even more recursive DNS servers).

Hence, I would welcome some discussion in the last § about the benefit of using
A QTYPE rather than  QTYPE and, as suggested by Erik Kline, please remove
the last 2 sentences.



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

[DNSOP] I-D Action: draft-ietf-dnsop-rfc7816bis-11.txt

2021-09-01 Thread internet-drafts 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Query Name Minimisation to Improve Privacy
Authors : Stephane Bortzmeyer
  Ralph Dolmans
  Paul Hoffman
Filename: draft-ietf-dnsop-rfc7816bis-11.txt
Pages   : 14
Date: 2021-09-01

Abstract:
   This document describes a technique called "QNAME minimisation" to
   improve DNS privacy, where the DNS resolver no longer always sends
   the full original QNAME and original QTYPE to the upstream name
   server.  This document obsoletes RFC 7816.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc7816bis-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc7816bis-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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

[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2021-09-15 CHANGED

2021-09-01 Thread IESG Secretary 
MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.

The Domain Name System Operations (dnsop) WG will hold
a virtual interim meeting on 2021-09-15 from 01:00 to 02:00 UTC.

Agenda:
The following drafts are on the agenda:
* dnsop-avoid-fragmentation
* dnsop-glue-is-not-optional 

Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=a910f22a-d46b-401f-be04-97c290437214

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

[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2021-09-15

2021-09-01 Thread IESG Secretary 
The Domain Name System Operations (dnsop) WG will hold
a virtual interim meeting on 2021-09-15 from 01:00 to 02:00 UTC.

Agenda:
The following drafts are on the agenda:
* dnsop-avoid-fragmentation
* dnsop-glue-is-not-optional 

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=m2e714c1c1a5a29e532d47a7461a63e2d

___
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

[DNSOP] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

2021-09-01 Thread Dan Romascanu via Datatracker 
Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-dns-tcp-requirements-12
Reviewer: Dan Romascanu
Review Date: 2021-09-01
IETF LC End Date: 2021-09-03
IESG Telechat date: Not scheduled for a telechat

Summary:

Ready with minor issues and editorial comments.

This document with intended status BCP updates RFC 1123 encouraging the
operational practice of permitting DNS messages to be carried over TCP on the
Internet. It is aligned with the implementation requirements in RFC 7766. It is
highly significant for the operators community as is the formal requirements
equivalent for the operational community, encouraging system administrators,
network engineers, and security staff to ensure DNS over TCP communications
support is on par with DNS over UDP communications and as it also considers the
consequences with this form of DNS communication and the potential operational
issues that can arise when this best current practice is not upheld.

This document is welcome and clear for anybody who is familiar with the field.
However, because of the long history it would be useful to think ahead for
readers that will read and use 5, 10 or 20 years from now. Hence, a few
editorial comments. I put them in the Nits/editorial category, but they are
really more than nits, so I recommend that the authors consider them, before
the document gets to the RFC Editor.

Major issues:

Minor issues:

1. In Section 4.1:

> DNS clients MAY also enable TFO when possible.

Maybe I do not fully understand the intent here, but 'MAY ... when possible'
sounds like a SHOULD to me.

2.In Section 4.2

>   DNS server software SHOULD provide a configurable limit on the total
   number of established TCP connections.  If the limit is reached, the
   application is expected to either close existing (idle) connections
   or refuse new connections.  Operators SHOULD ensure the limit is
   configured appropriately for their particular situation.

   DNS server software MAY provide a configurable limit on the number of
   established connections per source IP address or subnet.  This can be
   used to ensure that a single or small set of users cannot consume all
   TCP resources and deny service to other users.  Operators SHOULD
   ensure this limit is configured appropriately, based on their number
   of diversity of users.

The lack of recommendations about how these limits should be set would leave
less experienced operators in the dark. There is not even a sentence like 'This
document does not offer advice on particular values for such a limit' as for
other parameters in the same section. From an operators point of view I would
prefer a recommendation or one or more examples of how these limits can be set
in real life cases.

Nits/editorial comments:

1. Sections in the document that are obviously for informational pursposes
should be clearly marked so (like 'This section is included for informational
purposes only'). For example Section 2.

2. In Section 3:

Regarding the choice of limiting the resources a server devotes to
   queries, Section 6.1.3.2 in [RFC1123] also says:

  "A name server MAY limit the resources it devotes to TCP queries,
  but it SHOULD NOT refuse to service a TCP query just because it
  would have succeeded with UDP."

   This requirement is hereby updated: A name server MAY limit the
   resources it devotes to queries, but it MUST NOT refuse to service a
   query just because it would have succeeded with another transport
   protocol.

Similar alignment of the old and new text is desirable. Even using the OLD /
NEW format.



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