Re: [Last-Call] Benjamin Kaduk's Discuss on draft-crocker-inreply-react-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Dave,

On Wed, Mar 03, 2021 at 05:13:35PM -0800, Dave Crocker wrote:
> On 3/3/2021 12:20 PM, Benjamin Kaduk wrote:
> > On Wed, Mar 03, 2021 at 12:10:28PM -0800, Dave Crocker wrote:
> > My understanding is that it is intentionally a supported part of the
> > process for the IESG to be able to receive private feedback. 
> 
> Ben,
> 
> Of course.  And as an escape-hatch, for special circumstances, it's an 
> important option.
> 
> But when it is used as a means of bypassing public discussion?

If there was an attempt to bypass public discussion (note "if"), it does
not seem to have worked, given that there has been a substantial volume of
public discussion...

> Of the two contacts we know about, using that option for this draft, one 
> was not active in the public discussion.  Why?  The other was, but did 
> not raise these concerns in that forum.  Why?
> 
> This is important, for an organization with such a profound reliance on 
> open and inclusive participation and accountability.
> 
> There is a danger in not asking such 'whys' about people choice, because 
> it has too much potential for creating an image of cronyism and 
> back-room deals.

Speaking only for myself, I am interested in producing high-quality
technical documents.  I basically don't care by whom or in what forum a
potential issue is raised; I care about whether the technical content is
properly discussed (in an open forum, of course) and a satisfactory
resolution found.

I think we have had some recent threads over on [e-mail] that have
indicated the risks of attempting to assign motive to the words and actions
of others, and I do not expect to get involved in a discussion of why
anyone did or did not send what comments where at what time.

> 
> > The IESG or IESG members who receive feedback can do several things with
> > that feedback, including incorporating the technical points made into their
> > own ballot positions and asking for public discussion of those technical
> > points, with or without the direct involvement of the person who submitted
> > the feedback.
> > 
> > I think there's pretty universal sentiment that getting earlier feedback is
> > preferred, but I don't think that adding more process is going to cause the
> > phenomenon of late feedback to disappear.
> 
> "Preferred" is a characterization that makes a lot of sense for dealing 
> constructively when someone happens to think of something later.
> 
> However I suggest that it is entirely too weak for dealing with folk who 
> are attempting to bypass public discussion, especially when they already 
> have a track record of public participation.

If I put a Discuss position in, I and only I am on the hook to defend that
position.  Any other position does not block a document's approval.  If I
learn of an issue in a private discussion but I don't think it justifies a
discuss, that's in many ways the same as if I had never learned of that
issue at all.  If I do think the issue merits a discuss, then it's on me to
defend my position ... and it still doesn't matter where I learned of the
issue.  So where is the harm in receiving a private comment?  I only see a
risk that an issue actually should have blocked the document but did not,
which is the same situation as if no comment was made at all.  It seems to
me that attempting to forbid private comments would be much more likely to
result in no comments than in public comments, and that seems like a
strictly inferior situation to the current one.

> 
> > P.S. I think there is still an open (editorial) question regarding "the
> > message in which they both are present", for which I need more data to be
> > able to suggest a resolution.
> 
> I responded to that point.  The wording is the best we -- there was 
> public group discussion on it -- could come up with.

I put some thoughts into
https://mailarchive.ietf.org/arch/msg/last-call/T8Rm8E5KZ7-590Rj0QYnuTj1yeQ/
but do not see any follow-ups on the substance of this topic.  Please send
a link if I am missing something.

> If it is not sufficient, better wording is of course eagerly sought.

I would be happy to suggest better wording ... if I knew which to things
are indicated by the "both" in "both are present".  I think it's two of:
emoji as the content of a message part, the In-Reply-To header field, the
Content-Disposition: Reaction header field, the message being responded to,
and the message conveying the response.  But which two?

Thanks,

Ben