IETF conflict review for draft-moura-dnsop-authoritative-recommendations
conflict-review-moura-dnsop-authoritative-recommendations-02

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-moura-dnsop-authoritative-recommendations@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-moura-dnsop-authoritative-recommendations-10

The IESG has completed a review of
draft-moura-dnsop-authoritative-recommendations-10 consistent with RFC5742.

The IESG has no problem with the publication of 'Considerations for Large
Authoritative DNS Servers Operators'
as an Informational
RFC.

The IESG has concluded that this work is related to IETF work done in the
DNSOP WG, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-moura-dnsop-authoritative-recommendations/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

New version to remove this note to the IESG from the official conflict review response:

[ Background for the IESG / not an official part of the conflict review: This document was initially discussed in the DNSOP WG in ~2018. There was general interest (and no strong objections), and then some desultory discussions around adoption, but it was eventually decided / suggested (https://datatracker.ietf.org/doc/minutes-105-dnsop/) that this would be better published through the ISE stream]

[Ballot comment]
This is the right conflict-review response.

Having read the document:

Section 3.4.1

    They can withdraw its routes, pre-prepend its AS route to some or all of
    its neighbors, perform other traffic shifting tricks (such as reducing
    route announcement propagation using BGP communities[RFC1997]), or by
    communicating with its upstream network providers to apply filtering
    (potentially using FlowSpec [RFC8955]).

I suppose the work of the IETF DOTS WG might be one way to effectuate
such communication to apply filtering.