I join Harald in objecting to this recommendation without
further explanation, although for a slightly different reason:
--On Wednesday, January 27, 2016 11:10 +0100 Harald Alvestrand
<harald@xxxxxxxxxxxxx> wrote:
> This one surprised me a bit.
>
> Asking for blockage of an ind-sub is a fairly unusual thing.
> I kind of expected to find in the IESG review would explain
> the nature of the conflict, but the totality of the review is:
>
> "The IESG has concluded that this document violates IETF
> procedures about pervasive monitoring (RFC 7258) and should
> therefore not be published without IETF review and IESG
> approval. This work is related to IETF work done in the
> INTAREA WG."
>
> The procedures I could find described in RFC 7258 are these:
>...
But it is even more than anything specific to 7258: It might
be just a matter of poor phrasing, but the IESG objections
appears to say "this disagrees with an established IETF
position, therefore it should not be published without IETF
approval" and, by implication "approval that will never be
forthcoming because it agrees with an IETF established
position".
I don't think the IESG should be saying such things and that, if
they do, the ISE should ignore them. It has been an explicit
goal of what we now call the Independent Stream, since long
before we divided the streams up and gave them names or
established procedures for IESG review of independent
submissions, to be able to use the RFC Series to publish
specifications of, or dissents from, IETF (or NWG) positions.
If the IESG were to say "this isn't explicitly enough a dissent
or alternative" or "there is ongoing work with which this might
create confusion, please give us some months to finish up that
work so both can be published together" those would be entirely
reasonable statements/ requests and well within the bounds set
by RFC 4846. But the statement above appears to be an attempt
by the IESG to censor material with which it disagrees and,
independent of the substantive merits of this particular
document (or of 7258), we just should not go there.
> Note: I'm not arguing that this particular idea is bad or good.
> I'm saying that the IESG's justification for recommending it
> not be published needs to be more explicit about what the
> problem is, and why requesting an IESG note to be added saying
> "this is a Bad Idea" isn't a better IESG response.
What he said, although I think "this is a Bad Idea" IESG notes
should require justification, explanation, and an author
opportunity to rebut the IESG view.
john