Hi,

The working group does get to work on it. The specific suggested wording was about the scope of the document, which the chairs felt was consistent with what the WG had already decided about the document: that they were willing to work on it as an Informational description of the existing protocol.


This is why the original boilerplate wasn't acceptable for a WG document, and the authors have agreed to change it in order for it to be kept as a WG document.


Suzanne


On 7/18/17 8:30 AM, Ted Lemon wrote:
If the working group doesn't get to work on it, it seems more appropriate to publish it as an ISE document. This is what has been done in similar cases in the past.

On Tue, Jul 18, 2017 at 2:13 PM, Suzanne Woolf <suzworldw...@gmail.com <mailto:suzworldw...@gmail.com>> wrote:

    Dear colleagues,


    As you might recall, we had a call for adoption
    for draft-vixie-dns-rpz just before IETF 98 in March. We had a
    lively discussion and decided to adopt the document for further
    work in the WG as an Informational RFC.

    However, the chairs then discovered we’d made a mistake in
    adopting the draft with the copyright that reserved rights in
    derivative works to the original authors. This isn’t allowed for a
    Working Group document (see RFC5378, Section 3.3).

    We’ve talked since then with the authors about how we might move
    forward with the draft. They had concerns, which had already been
    discussed on the list, about some of the views of the WG on the
    applicability of RPZ.

    We believe we’ve found a way forward that meets their concerns and
    the needs of the WG. We propose that:

    1. The draft adopts the following language in the Introduction:

        This document describes an existing and widely deployed method
        by which a security policy can be applied to DNS responses,
        possibly causing an end system to receive responses that do
        not correspond to actual DNS zone content. Such policy-based
        responses might prevent access to selected HTTP servers, or
        redirect users to "walled gardens", or block objectionable
        email, or otherwise defend against DNS content deemed
        malicious by the RDNS operator and the end-user.

        This method describes its policy using a specially formatted
        DNS Zone called a Response Policy Zone (RPZ), and is an
        instance of a more general mechanism called a "DNS Firewall."
        Like other mechanisms called "firewalls," response policy
        zones (RPZ) can be used to block both wanted as well as
        unwanted data.  RPZ ought not be used to interfere with data
        desired by recipients. In other words, RPZ should be deployed
        only with the permission of every affected RDNS end-users.

        This document does not recommend the use of RPZ in any
        particular situation or instead of other mechanisms including
        those more commonly called "firewalls."  This document lacks
        an applicability statement for that reason, and because it
        merely describes a currently common practice, without
        recommending or criticising that practice. By design and
        expectation, response policy zones (RPZ) must be seen as a
        defensive and virtuous tool, or it will either not be used, or
        will be bypassed by end-users.


    2. We had already limited the the scope of the document to
    describing the current protocol, with any discussion of proposed
    changes left to a later document if people want to do that work.
    That limitation stands. The intended document status is Informational.

    3. The copyright is changed to the standard boilerplate required
    for a WG draft.


    If this is acceptable to the WG, we’ll keep the new draft with
    these changes as a WG draft.

    If not, the draft will be dropped as a WG item. The authors can
    seek publication of the document as an independent submission or
    outside of the RFC series.

    If you have a comment on this, please make it succinctly and soon.


    thanks,
    Suzanne & TIm

    _______________________________________________
    DNSOP mailing list
    DNSOP@ietf.org <mailto:DNSOP@ietf.org>
    https://www.ietf.org/mailman/listinfo/dnsop
    <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

Reply via email to