Skip to main content

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

Yes

(Alissa Cooper)

No Objection

(Magnus Westerlund)
(Mirja Kühlewind)

Abstain


Note: This ballot was opened for revision 03 and is now closed.

Ballot question: "Is this the correct conflict review response?"

Warren Kumari
No Objection
Comment (2019-06-24) Not sent
[ 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.
Alissa Cooper Former IESG member
(was Discuss) Yes
Yes () Sent for earlier

                            
Barry Leiba Former IESG member
Yes
Yes (2019-06-01 for -03) Sent
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.
Magnus Westerlund Former IESG member
No Objection
No Objection () Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection () Not sent

                            
Adam Roach Former IESG member
Abstain
Abstain (2019-06-20) Sent for earlier
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.
Alvaro Retana Former IESG member
Abstain
Abstain (2019-06-21) Sent
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.
Deborah Brungard Former IESG member
(was No Objection) Abstain
Abstain (2019-06-21) Sent
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.
Martin Vigoureux Former IESG member
Abstain
Abstain (2019-06-27) Not sent
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.