Reaction: Indicating Summary Reaction to a Message

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

Éric Vyncke Yes

Comment (2021-02-23 for -08)
Interesting idea and easy to read document.

May I assume that the choice of a non-existing day in the example (29th of February in 2021 :) ) is on purpose ?

Perhaps a nits in section 4.1, should there be a space character after ':' in "" ?

Another nit, while I do appreciate Barry Leiba (and this is the last document from Barry that I am reviewing), is it necessary to list him twice in the acknowledgement section ?



Alvaro Retana No Objection

Erik Kline No Objection

Martin Duke No Objection

Martin Vigoureux No Objection

Robert Wilton No Objection

Comment (2021-02-22 for -08)
Good luck with the experiment, it sounds interesting, and I hope that it works out positively.


Roman Danyliw No Objection

Comment (2021-02-24 for -08)
No email
send info
Thank you to Adam Montville for the SECDIR review.

Warren Kumari No Objection

Comment (2021-02-25 for -08)
No email
send info
I must admit that I really don't like the base idea. Emoji's annoy me, and I'd much rather that people reply to messages with a written reply instead of some hard to interpret picture of a upside down hose eating a banana.... but, I'll fully acknowledge that all the cool kids are doing it, and I'm clearly old and curmudgeonly. 

Luckily, my opinions on if emojis and thumbs up are not actually important here -- the proposed solution seem to work, and so while I personally hope that this never catches on, I'm balloting No Objection (with a side-order of soapbox opining... )

Benjamin Kaduk (was Discuss) Abstain

Comment (2021-03-12 for -11)
No email
send info
Though this is not the reason for my abstention, the IANA
Considerations section remains inconsistent with the structure
of the registry in which it is requesting allocation.

Murray Kucherawy (was No Objection) Abstain

Comment (2021-04-13 for -11)
Thanks for addressing my previous comments.

During post-last-call discussion, concerns were raised regarding appropriate recognition for contributors in the Acknowledgements section of this document.  I conducted a searching review of this topic while preparing these comments, including seeking the advice of IETF counsel, and I thank the interested parties for their patience as I did my research.

Although it has been suggested that BCP 78 (Section 5.6) and BCP 9 (Section 10.3.1) are instructive about what should be included in Acknowledgements, IETF oral tradition grants authors and editors wide latitude in this regard.  Also, notably, while BCP 9 is fairly limited in terms of what it says needs to go into Acknowledgements (mainly “major contributors”), BCP 78, which formally updates BCP 9, is markedly more liberal on this point.  Collectively, this naturally means there is no clear answer.

In its response to an appeal in 2013, the IESG declined to intervene in a similar case, deferring instead to the discretion of the document author.  The disposition of that appeal, as is the case here, appears to pivot on the author’s discretion with respect to whether the contribution was “major”.

On review, it is my personal opinion that certain text at the end of the current document’s Sections 3 and 5 was the synthesis of some of that discussion.  I do not, however, have an opinion as to whether these contributions qualify as “major”.  While I have urged, and with these comments do so again, that this discretion be reconsidered given the broad intent of BCP 78 and the typical (but less formal) guidance to be comprehensive and transparent with acknowledgements, I decline to obstruct progress of this document on that basis at this point in its life cycle.

Though not a formal appeal, this is now the second time this question has been raised to the level of the IESG for consideration.  As such, I suggest that the issue may be ripe for the community to discuss and contemplate more firm guidelines in this space.  For an organization already concerned with attrition and attracting newer participants, and with the very real risk of rather contentious formal proceedings, this is an area in which I believe we would do well to reach stronger consensus.

(Barry Leiba; former steering group member) (was Discuss, Yes) Yes

Yes (2021-02-25 for -08)
No email
send info
There are still some issues that I'm trying to get aired on the last-call list, mostly related to limiting the set of allowed emoji characters.  I'm leaving this at the non-blocking comment level now.

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection (2021-02-25 for -08)
I have to say that I am a bit worried about two things with this specification. They are both in some sense raised.

The first is the user aspects of knowing who the response is going to. Is this being sent to just the sender or all recipients. And are the reaction bundled with a reply or sent separately? 

Secondly, is the operational aspect of reactions going to all recipients and mailing lists. This appears that it can cause a lot of messages and especially for the people that don't have a MUA that support this will gets a lot of bewildering emails.