On 18 Apr 2021, at 11:47, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > > Perhaps we can define a better way of giving pushback than snarling. > But I'm pretty sure that we could also do worse than letting people > express their dislike for ideas in their own words. I'd be especially > wary of defining some standard "polite" way of rejecting Bad Ideas > that doesn't let people express themselves. We need some flexibility > in how we give pushback, so that some people can open up doors at least > a little bit, even if other people want to slam them shut. > > Maybe it would help to have some concrete suggestions for non-snarling > ways of pushing back on Bad Ideas. As in "if you can't find better > language to use, try one of these boilerplate alternatives". That is a truly excellent suggestion. Your idea would be more clearly expressed in an internet-draft, which we look forward to seeing in due course. As far as we can tell, your basic idea is sound. We look forward to seeing it progress in a different workgroup. We need to define these alternatives in a BRUSH-OFF BOILERPLATE (BROFF) workgroup, which we can form by holding a BROFF BOF. The output of that WG can be an informational RFC making advisory recommendations on how to effectively handle and respond to bad, poorly thought out, unwelcome, ill-advised, or ahead-of-their-time ideas. Of course, BROFF will be presumed to be working on RFC editing markup, so we'll immediately need to decide a better name at the BROFF BOF; say, Idea Acknowledgement and Action (IDEATION)? The informational RFC will specify sample response boilerplates, which will be something generated using a simple tool based along the lines of these skeleton choose-your-own-acknowledgement checkboxes in an outline decision-tree format, below. This is very much an early draft laying out the basic idea with some filler, not set in stone, and would need considerable revision during the BOF and until eventual WG acceptance. INSTRUCTIONS TO DESIGNATED FIRST RESPONDERS: tick boxes that are relevant, and assemble your reply from that. Dear [INSERT NAME HERE]. thankyou for your suggested idea in [INSERT WORKGROUP HERE]. [] Your idea would be [] better [] more clearly [] more fully expressed in [] an [] a different internet draft, [] which we look forward to seeing in due course. [] which would be suitable for another workgroup. [] from other authors. [] As far as we can tell, your basic idea [] which has been said before [] many times [] by others [] by you [] is sound [] but has been evaluated and rejected as not viable [] at this time [] each and every time for [REASONS]. [] sounds as if it could have been sound, but [REASONS]. [] needs sounding boards outside this WG. We suggest [ANOTHER SELECTED WORKGROUP]. [] is unlikely to be progressed, because [] it is not within the scope of this workgroup [] but it is in scope for [ANOTHER SELECTED WORKGROUP]. [] while it is in the scope of this workgroup, it is not in its charter. [] it is in the scope and charter of this workgroup, but alongside already established work, which is [] taking all our time and effort. [] sucking all the air out of the room. [] supported and invested in by almost everyone else. [] [REASONS] [] that problem just can't be fixed. [] Everyone else has already tried. [] it's a new transport protocol. Space for those is exhausted. [] There's the QUIC and the dead, so this must already be dead. [] and its congestion control would need work. [] it requires a 'flag day' changing everything on the Internet. [] it requires a 'flag day' changing the known laws of physics. [] it requires a 'flag day' changing capitalism. [] it, without explanation, [] invokes and relies on the availability and use of [] blockchain [] NFTs [] 'the cloud' [] quantum entanglement [] the 'quantum blockchain cloud' [] IPv6. [] uses unfamiliar terminology. [] including 'quantum blockchain cloud'. [] uses familiar terminology, but not in a way that that terminology is used. [] invents an entirely new language for networking. [] it increments the version number of an existing protocol without justification. [] it decrements the version number of an existing protocol without justification. [] it does not consider the end-to-end principle. [] it relies on the end-to-end-principle, which fell out of favor over a decade ago. [] it does not consider the RESTful architecture. [] it relies on the RESTful architecture, which fell out of fashion a decade ago. [] it expects multicast use to work. [] it expects IPv6 use to work. [] it raises important security concerns, which are [] obvious [] non-obvious [] but require too much explanation [] sadly not interesting enough to describe in detail. [] it expects us to work for, rather than with, you. [] With much more added explanatory detail, your idea [] may meet with a better reception. [] may not meet with any improved reception. [] will have much more added explanatory detail. We thank you for taking the time to present your idea to us and to make a contribution. Your efforts and enthusiasm have [] unfortunately not gone unnoticed. We look forward to [] more considered [] better documented [] more aligned-with-reality-as-we-see-it [] more politically acceptable [] improved future ideas from you [] and to seeing those ideas progress in [ANOTHER SELECTED WORKGROUP].
