IETF conflict review for draft-nottingham-safe-hint
conflict-review-nottingham-safe-hint-04

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

The IESG has completed a review of draft-nottingham-safe-hint-10 consistent
with RFC5742.

The IESG has no problem with the publication of 'The "safe" HTTP Preference'
as an Informational RFC.

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

The IESG would like the following IESG note added to the document:

-----------------------

Given the current requirements for registering HTTP preferences [RFC7420], the
relationship between this document and those registry requirements is unclear.
The document claims that its purpose is to specify a common understanding of
how the "safe" HTTP preference operates, but this is not achieved since there
is no semantic defined for "safe." The registration policy for the HTTP
preferences registry is Specification Required, so an RFC is not necessary in
order to simply register this preference.

This mechanism was presented for publication as an IETF Proposed Standard, but
was not approved for publication by the IESG. Concerns raised by the IESG
remain valid. Some of these concerns are addressed or discussed in the
document, but others are not, such as how the use of this preference may
incentivize increased censorship and/or targeting of minors.

-----------------------

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-nottingham-safe-hint/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-nottingham-safe-hint/

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

Thank you,

The IESG Secretary

[Ballot comment]
I note that the draft says:
  The mechanism described in this document does not have IETF consensus
  and is not a standard.
And few lines below:
  This mechanism was presented for publication as an IETF Proposed
  Standard, but was not approved for publication by the IESG despite
  having IETF consensus at that time.

I think it would be good to resolve in the document what appears to be an inconsistency and I'm not sure the second part of the IESG note clarifies that.

[Ballot comment]
[ Note: I had multiple browser tabs opened, and accidentally typed my ballot in 'draft-nottingham-safe-hint' instead of 'conflict-review-nottingham-safe-hint'. Copied below]

I am balloting No Objection, not because I approve of the document itself, but rather because I believe in the ISE's right to publish what they see fit; if I were balloting on the document *itself* I'd probably ballot Discuss[0], but this has now morphed into balloting on the inclusion of the IESG Note.

While I would *like* the ISE and authors to address the questions raised in the Conflict Review IESG Note I respect their independence.  As I do not see this actively breaking any IETF technology, I feel that the only response I can give is No Objection.

[0]:I think that it is not very well described and that there are risks... but this isn't my call to make.

[Ballot comment]
My original concerns related to the history of this document have been addressed.

I think that Alissa's Discuss (and the current proposed IESG Note) raise significant issues that should be addressed *in* the document.  Specifically,  the lack of objectivity in the definition of "safe" and the potential unwanted results (from increased censorship to not even attempting to provide appropriate content to minors) are mentioned in passing throughout the document -- but I think they should be explicitly and clearly addressed.  Even if this document is not the product of the IETF, potential confusion from casual readers justify the explicit treatment.  I encourage the ISE to work with the author to do so.

Similar to Adam's position, it seems that wanting to include explicit coverage in the document itself goes against the proposed response and the existing Discuss.  Even though I think the intent is congruent, I am ABSTAINing.

[Ballot comment]
Adam's Abstain triggers me to also move to "Abstain". Looking back on this document's history, I noted Stephen's previous (1/19/15) ballot of Discuss (resulting in his Abstain), where he also voiced his concerns on the document and questioned the "IETF consensus" statement. I don't see the value/appropriateness of trying to rationalize this as having IETF consensus but the IESG as blocking. A simple statement of "this document was not approved for publication as Proposed standard due to concerns..." would be sufficient.

[Ballot comment]
Given the caveats at the end of this document's introduction, I think the originally-proposed response is more appropriate than one that calls for an IESG note. The document already disclaims being an IETF product (although see my second comment below). I don't want to stand in the way of making progress, though, so I'm going to abstain rather than registering a discuss that can't fundamentally be reconciled with the existing discuss.

I have two notes that involved parties may wish to take into consideration.

The first, for Barry: if we do ultimately ask the ISE to add a note, there is a typo in the current formulation, which points to RFC 7420 rather than RFC 7240.

The second, for Adrian: the current version of the document indicates: "This mechanism was presented for publication as an IETF Proposed Standard, but was not approved for publication by the IESG despite having IETF consensus at that time." This statement seems controversial and potentially inflammatory in light of the first point of the discuss position (now changed to an abstain) balloted at https://datatracker.ietf.org/doc/draft-nottingham-safe-hint/ballot/#stephen-farrell . I do not believe the statement adds value to the document, and it appears to be overstepping bounds by implying some level of IETF sponsorship that I feel is not appropriate for documents published by the ISE. Accordingly, I would encourage the ISE to remove this passage.

[Ballot comment]
Given the caveats at the start end of this document's introduction, I think the originally-proposed response is more appropriate than one that calls for an IESG note. The document already disclaims being an IETF product (although see my second comment below). I don't want to stand in the way of making progress, though, so I'm going to abstain rather than registering a discuss that can't fundamentally be reconciled with the existing discuss.

I have two notes that involved parties may wish to take into consideration.

The first, for Barry: if we do ultimately ask the ISE to add a note, there is a typo in the current formulation, which points to RFC 7420 rather than RFC 7240.

The second, for Adrian: the current version of the document indicates: "This mechanism was presented for publication as an IETF Proposed Standard, but was not approved for publication by the IESG despite having IETF consensus at that time." This statement seems controversial and potentially inflammatory in light of the first point of the discuss position (now changed to an abstain) balloted at https://datatracker.ietf.org/doc/draft-nottingham-safe-hint/ballot/#stephen-farrell . I do not believe the statement adds value to the document, and it appears to be overstepping bounds by implying some level of IETF sponsorship that I feel is not appropriate for documents published by the ISE. Accordingly, I would encourage the ISE to remove this passage.

[Ballot discuss]
I do not believe all the concerns previously raised by the IESG have been clarified in this document, so I'm not comfortable with the proposed IESG note text. I also think there is an inconsistency between the claim in the document about why it exists and the registry requirements for HTTP preferences. So I would like to suggest a different IESG note:

"Given the current requirements for registering HTTP preferences [RFC7420], the relationship between this document and those registry requirements is unclear. The document claims that its purpose is to specify a common understanding of how the "safe" HTTP preference operates, but this is not achieved since there is no semantic defined for "safe." The registration policy for the HTTP preferences registry is Specification Required, so an RFC is not necessary in order to simply register this preference.

This mechanism was presented for publication as an IETF Proposed Standard, but was not approved for publication by the IESG. Concerns raised by the IESG remain valid. Some of these concerns are addressed or discussed in the document, but others are not, namely how the use of this preference may incentivize increased censorship and/or targeting of minors."

[Ballot comment]
I found the proposed IESG note and 1st paragraph of the introduction proposal to conflict with the 2nd paragraph as one says there was no IETF consensus and the other says there was IETF consensus. Need to sort out to be consistent.

[Ballot comment]
I strongly object to the request for an IESG note that says nothing useful.  What we want will already be in the document.  I appear to be in the rough on this, so I'm balloting "yes" to move this forward.  But this is not what IESG notes are intended for.

[Ballot comment]
There are some good points in the existing Discuss/Abstain positions, that I won't repeat.

Some general comments not specifically related to the conflict review response:
it is probably a bit late to do anything about this, but the name "safe" seems incredibly
generic and it's not entirely clear that this is the most appropriate usage to attach to
such a generic term.

[Ballot discuss]
The controversial nature of this document [1], including its history (as it already went through the WG process and IESG Evaluation before moving to the ISE stream), warrants additional text along the lines of what was suggested in Alissa’s ballot…something like: this document is not the product of IETF consensus and/or the IETF does not endorse the use of the proposed mechanism…  [The responsible AD is in a better position to determine the precise text.]

[1] https://mailarchive.ietf.org/arch/msg/iesg/IF4DPXogP4asE0lGmGdsRfFq29o

[Ballot discuss]
To be honest I really don't understand the process we apply here. The HTTP Preferences registry is "Specification Required", however, I thought we had a discussion a while ago that a draft is sufficient for this. This document clearly extends an IETF protocol and even though IETF consensus is not required for the registration, I really don't understand why this document is not published within the httpbis group (or as AD sponsored - also I don't think "the wg is to busy with other stuff" is a good argument for AD sponsorship).

[Ballot comment]
This is a good example of a document that I expect the broader public to confuse for an IETF consensus document that has the IETF's endorsement. So while it may not directly conflict with ongoing IETF work, I don't feel comfortable balloting no objection on the conflict review.