Subject: Proposal: an "important-news" IETF announcement list

From: IETF Chair <[email-masked]>
Date: Fri, 24 Sep 2021 10:25:55 +0300

Hi,

at the moment, ietf-announce is the main announcement list of the IETF,
seeing regular posts from various roles and bodies in the organization,
and from the Datatracker. Over the last year, ietf-announce has seen
around 1200 emails, averaging around 4.6 emails per workday.

The ietf-announce lists currently distributes the following types of
announcements. All but the first type are automatically generated by
various tools:

1.  Announcements sent manually by the IETF Chair, the IAB Chair, the
    IRTF Chair, the Chair of the LLC Board, the IETF Executive Director,
    the NomCom Chair, and the IETF Secretariat
2.  Announcements of new and updated WG charters
3.  WG closure announcements
4.  Announcements of new non-WG mailing lists
5.  Announcements of new RFCs
6.  IESG and LLC telechat announcements
7.  Announcements of document actions
8.  Announcements of IESG conflict-review results
9.  Last call announcements for I-Ds
10. Interim WG meeting announcements

The ietf-announce list currently has 3095 subscribers, which is a
fraction of the overall IETF community. Only 961 of these subscribers
have Datatracker accounts; out of 13311 overall Datatracker account
holders. When asking IETF participants about why they are not
subscribed, the volume of email on the list
- especially automatically-generated Datatracker email - is the most often
mentioned reason.

The IESG is therefore considering creating a new mailing list for
important organizational announcements only. We are hoping that a
subscription to a new low-volume mailing list will be acceptable to
IETF participants that find ietf-announce too noisy, and will help us
disseminate important news and announcements more widely and effectively.

Here are the details about this proposal:

* The name of the new mailing list is important-news.

  - The ietf-announce mailing list will continue to operate as-is.

  - Posting rights to important-news are restricted to the same set of
    roles as for ietf-announce.

  - All emails sent to important-news will be CC’ed to ietf-announce.

* Posts

  - important-news will only receive the first type of announcements in
    the numbered list above, i.e., important announcements that are
    manually sent by various organizational roles.

  - important-news will not receive any of the other types of email sent
    to ietf-announce. In the rare case that one of these is of
    sufficiently broad community interest to be distributed via
    important-news, this will occur as a manual action by one of the
    roles authorized to post to important-news.

* Subscriptions

  - Every participant with a current Datatracker account will be
    automatically subscribed to important-news.

  - Every participant creating a new Datatracker account will
    automatically be subscribed to important-news.

  - important-news is also open to manual subscriptions to anyone
    without a Datatracker account. A welcome message will be sent to
    new important-news subscribers, explaining what it’s for and that
    we’d hope they stay subscribed. It will also include instructions
    or ideally a link for unsubscribing.

  - Any important-news subscriber can unsubscribe at any time.

The IESG is inviting community feedback to [email-masked] about this
proposal by 7 October 2021.

Lars Eggert
IETF Chair (on behalf of the IESG)

---

From: Melchior Aelmans <[email-masked]>
Date: Fri, 24 Sep 2021 16:11:33 +0200

I think  this would be helpful to make sure no important messages are
missed.
Thanks for the effort!

Cheers,
Melchior

On Fri, Sep 24, 2021 at 9:27 AM IETF Chair <[email-masked]> wrote:

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 24 Sep 2021 21:15:07 +0200

The idea is not bad, but i think there is another division which would
be more helfull:

a) IETF calendar stream
   For events and event related deadlines

b) IETF WG and document stream
   For WG/BOF status/charter and document related announcements/deadlines

I think what would help most participants to easier participate in IETF
work would really be to work on solutions for an IETF calendar:

- main meetings, interims, workshops (IAB and other), public directorate
  meetings, IESG/IAB offsites, IESG telechats, etc. pp. And deadlines
  related to them.

  Even if some of the events are non public, its always good to know
  when e.g.: leadership is absent for e.g.: offsites and the like. And
  several meetings are non-public to attend but public streamed. And/or
  streams/recordings are available afterwards. All of this is right now
  scattered around different places for different type of events,
  so it is hard to find. Especially afterwards for streams/minutes

Maybe in before building such a web tool, just think about two simple
starting points:

- ietf-calendar mailing list that bundles all the relevant announcements
  we already have as well as the ones we are missing. E.g.: there are
  directorate and other public meetings that are NOT announced to
  community-wide mailing lists, maybe because they feel tthere is no
  good list to do so.

- "Next Week in IETF newsletter". List of next weeks IETF events/deadlines
  to be sent as email by friday morning the prior week. 
  
  This would ultimately be the easies, most compact form of information,
  and likely will be more read than even "important-news".

  And of course, with a name like that it could easily include any
  more specific non-calendar information leadership feels to be most
  important.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Sep 2021 14:56:55 +1200

Hi,

I have to say that it never ceases to amaze me that anyone with a profession
or hobby that includes a few IETF WGs would find 4.6 messages/day a
burden. It isn't even noise. However, so be it, so please try this out.

My comments:

1. Make it explicitly a one-year experiment. If it fails (fewer than 3095 
subscribers, for example), drop it.

2. Make it opt-out for meeting registrants. Ideally, it would also be opt-out for anyone who subscribes to any IETF list whatever, but I don't know if that's practicable.

3. I do object strongly to classifying "Last call announcements for I-Ds" 
as non-important. They are such a fundamental part of the IETF process that they really must go to everybody, and specifically to everybody who is 
*not* in the WG concerned. In fact, this would amount to an end-run around RFC2026, for standards track and BCP drafts.

Regards
   Brian Carpenter

---

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 25 Sep 2021 17:26:23 +1000

> *not* in the WG concerned. In fact, this would amount to an end-run around RFC2026, for standards track and BCP drafts.

I would pretty strongly push back again this.  There are whole areas of the IETF in which I have no interest, or even if I have interest, I have no special expertise that would make my contribution on them valuable.

I'm significantly more interested in seeing everything in my area (ART) because I'm more likely to have something of value to add - but even there, it's a wide enough cross section that there are parts I don't particularly need to know about and spend mental energy on.

And I'm pretty invested and interested in the IETF compared to plenty of people who want to come in and work on one particular thing.  If we want the IETF to be welcoming and non-overwhelming to new people, making "you have to have an opinion on every piece of work in the firehose" be the default is pretty unfriendly. It just doesn't scale.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Sep 2021 03:56:25 -0400

IESG,

I agree with Brian.  

However, his note suddenly brought something I've been thinking
about on and off into focus.  While it would be really
unfortunate to have it turned into a rule we tried to enforce in
any way, perhaps we should be thinking less in terms of
"participation in the IETF is free and carries no obligations
other than being nice".  Instead, we should be thinking more
along the lines of "there is a price to participate in the
IETF... and it is participating in the IETF".  We talk about
ourselves as a community and claimed for decades that one of our
strengths relative to other standard development organizations
was that our participants were concerned about a better
Internet, not just agreeing on specifications for a largely
disconnected series of products.  

There will certainly be times when having experts working on
particular topics and ignoring just about everything else is
necessary and appropriate, but maybe we should be focused more
on a healthy and developing Internet, and on an IETF with broad
participation, rather than on ways to making it easier to ignore
Last Calls and community discussions.  

Bron is right and I'm not suggesting anything like having to be
educated and engaged on "every piece of work in the firehouse"
(I don't think Brian was either).  But a more general sense of
what is going on, including the realization that assignment of
particular work to Areas is sometimes arbitrary, can be useful.
(Examples omitted to save space.)

I think the IETF would benefit if the IESG, when considering
fragmenting mailing lists so that people get only those messages
they really, really, want or taking other actions that make it
easier to not participate except on very narrow work areas,
would more obviously consider the costs to the community of
doing so.   Even if the decisions don't come out differently, I
think more obvious attention to those costs would be beneficial.

best,
   john

--On Saturday, September 25, 2021 14:56 +1200 Brian E Carpenter
<[email-masked]> wrote:

> Hi,
> 
> I have to say that it never ceases to amaze me that anyone
> with a profession or hobby that includes a few IETF WGs would
> find 4.6 messages/day a burden. It isn't even noise. However,
> so be it, so please try this out.
> 
> My comments:
> 
> 1. Make it explicitly a one-year experiment. If it fails
> (fewer than 3095  subscribers, for example), drop it.
> 
> 2. Make it opt-out for meeting registrants. Ideally, it would
> also be opt-out for anyone who subscribes to any IETF list
> whatever, but I don't know if that's practicable.
> 
> 3. I do object strongly to classifying "Last call
> announcements for I-Ds"  as non-important. They are such a
> fundamental part of the IETF process that they really must go
> to everybody, and specifically to everybody who is  *not* in
> the WG concerned. In fact, this would amount to an end-run
> around RFC2026, for standards track and BCP drafts.
> 
> Regards
>    Brian Carpenter

---

From: [email-masked]
Date: Sat, 25 Sep 2021 06:14:49 -0700 (PDT)

I'm afraid I have to agree with Bron on this.

> > *not* in the WG concerned. In fact, this would amount to an end-run around
> > RFC2026, for standards track and BCP drafts.

This aspect of the IETF process was in its death throes back in 2000-2004 when 
I was on the IESG and should have been pronouced dead a few years after that.

Not only was any sort of truly comprehensive cross-area review becoming
increasingly difficult due to growth in technical complexity, comments when
made were starting to be met with increasing hostility. (And while some of the
latter was pure NIH, a lot of it was reluctance to spending the time to try and
explain things requiring a deep understanding of both the technology as well as
how we got to this point to people who, expertise in their own areas
notwithstanding, had no real familiarity with the subject matter.)

And yes, I'm well aware (and so, unfortunately, is my wife) of the potential
value of having to explain something to someone who is capable but who isn't
immersed in the subject matter. I also know the various anecdotes where this
has proved to provide invaluable insights.

But, to take the obvious example, not every problem is as important as a
shuttle crash and not every outside reviewer is as smart as Richard Feynman. So
the sad reality is that the possible benefits of cross-area review don't seem
to justify the cost.

Or maybe they do, but we have structured things so that we're oblivious to it.
For exmaple, ART only deals with a very small fraction of application protocol
development. This has led to the development of entire protocol ecosystems like
the one associated with Java. I think I can safely say that a little more cross
area review here, especially in regards to security, might have been helpful in
this case.

But no matter how much any of may dislike the present situation, we are where
we are. As it happens I think we are focusing on the wrong problem here (more
on that later), but that may be because I use filtering rules so I don't
have to look at I-Ds, last calls, and comments on drafts in areas I don't
follow, and so don't really care how the IETF structures the way it sends
stuff out. (This is beauty of email, as opposed to dumpster fires like Slack.)

> I would pretty strongly push back again this.  There are whole areas of the
> IETF in which I have no interest, or even if I have interest, I have no special
> expertise that would make my contribution on them valuable.

I rather suspect you're selling yourself short here in regards to the potential
value of your input, but that's beside the point. None of us are getting paid
to do this sort of thing, and nobody has a right to demand that you take an
interest that you don't see any benefit in following.

> I'm significantly more interested in seeing everything in my area (ART)
> because I'm more likely to have something of value to add - but even there,
> it's a wide enough cross section that there are parts I don't particularly need
> to know about and spend mental energy on.

Exactly right. Mental energy is precious.

> And I'm pretty invested and interested in the IETF compared to plenty of
> people who want to come in and work on one particular thing.  If we want the
> IETF to be welcoming and non-overwhelming to new people, making "you have to
> have an opinion on every piece of work in the firehose" be the default is
> pretty unfriendly. It just doesn't scale.

Also a very good point.

				Ned

---

From: Bob Hinden <[email-masked]>
Date: Sat, 25 Sep 2021 09:03:19 -0700

Lars, IESG,

I have some questions that would be helpful to know before evaluating this proposal.  See below.

Bob

> On Sep 24, 2021, at 12:25 AM, IETF Chair <[email-masked]> wrote:
> 
> Hi,
> 

Like what Brian and other have said, 4.6 emails per workday doesn’t seem like a burden to me.  BTW, assuming “workday” means Monday-Friday, it’s only 3.3 emails per day over a year.

> 10. Interim WG meeting announcements

Please break this down further.   That is, how many emails of each type per year.  It’s hard to evaluate this proposal without knowing that.

> holders.

This is disturbing.   How can one function in the IETF when you aren’t getting information about meetings, draft deadlines, new working groups, BOFs, etc.?

How many of these data tracker accounts are active?    I wouldn’t be surprised that a large portion of them haven’t been used for a while, or sent email, etc.

> When asking IETF participants about why they are not

How many "automatically-generated Datatracker email” are there?  Are all except for 1. in the numbered lists data tracker generated?

> * The name of the new mailing list is important-news.

Suggest “ietf-important-news”, like “ietf-announce”.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 25 Sep 2021 10:59:41 -0700

I think I am with Bob and Brian on this one. With some nuances.

> Like what Brian and other have said, 4.6 emails per workday doesn’t seem like a burden to me.  BTW, assuming “workday” means Monday-Friday, it’s only 3.3 emails per day over a year.
The problem is that if most of those emails feel like noise, the 
receivers will most likely filter the mailing list and either ignore it 
all or put it in some folder for "view that when I have time". Noisy 
mailing lists get ignored, or just not subscribed.
> Please break this down further.   That is, how many emails of each type per year.  It’s hard to evaluate this proposal without knowing that.
It feels like a lot of this looks like "the log of the IETF". Rather 
than splitting the mailing list in parts, have we considered not using a 
mailing list in the first place? If the point is to have a log, then 
have a log on the web site, and use keywords so people can quickly view 
"what is new in transport or security", or some such preferences.
> How many of these data tracker accounts are active?    I wouldn’t be surprised that a large portion of them haven’t been used for a while, or sent email, etc.
How many of the subscribers do actually read it?
>> proposal by 7 October 2021.

I have two different sources of mixed feelings about this.

First, If we create an "important" list, will more people unsubscribe 
from the "announce" list? Is that the desired effect? If we do this 
experiment, will we monitor the "announce" list?

Second, who exactly defines what is important? Is that another way to 
empower people in elected positions, relative to the average participant?

-- Christian Huitema

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 Sep 2021 21:36:40 +0100

I promised I wouldn't get sucked in, but reading Bob's latest I find myself typing anyway.

> Suggest “ietf-important-news”, like “ietf-announce”.

Can we avoid mailing list title inflation?
Just "ietf-news" should do the job.

>>  - All emails sent to important-news will be CC’ed to ietf-announce.

Really? Why? This seems to totally deny the value of a new list. It is also not very pleasant in the context of the "mandatory subscription" described below because now people will get two copies of emails.

>>    automatically subscribed to important-news.

Please don't do that. It is inertia subscription. That is not nice in my opinion.

How about sending each Datatracker account registered email address an email offering them "click here to subscribe"?

>>    automatically be subscribed to important-news.

This can be handled with a check box during account creation so that the account holder has the option.

>>  - Any important-news subscriber can unsubscribe at any time.

Which is fine, but requires opt-out action which should not be the default.

Ciao,
Adrian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Sep 2021 08:57:08 +1300

On 25-Sep-21 19:26, Bron Gondwana wrote:
>> as non-important. They are such a fundamental part of the IETF process 
that they really must go to everybody, and specifically to everybody who is 
> I would pretty strongly push back again this.  There are whole areas of the IETF in which I have no interest, or even if I have interest, I 
have no special expertise that would make my contribution on them valuable.

Bron, that isn't the point. Of course no individual can be expected to comment on the subject matter of every last-called draft. But the whole point (and here I am much less pessimistic than Ned Freed) is to awaken the interest of someone who simply hasn't been aware of a draft but who does happen to have sufficient knowledge to find unexpected issues.

If our area review teams plus GenArt were 100% perfect, this wouldn't be necessary, but they aren't.

There are maybe 300 IETF Last Calls per year. I calculate that the ones I 
ignore cost me about 600 seconds per year to glance at the message and hit the delete key. I can identify four drafts where I've sent comments in response to an IETF Last Call in the past year (not counting WGs that I track and my own GenArt reviews). I have no idea whether that is typical.

> I'm significantly more interested in seeing everything in my area (ART) 
because I'm more likely to have something of value to add - but even there, it's a wide enough cross section that there are parts I don't particularly need to know about and spend mental energy on.
> 
> And I'm pretty invested and interested in the IETF compared to plenty of people who want to come in and work on one particular thing.  If we want the IETF to be welcoming and non-overwhelming to new people, making "you have to have an opinion on every piece of work in the firehose" be 
the default is pretty unfriendly. It just doesn't scale.

But that's not what we ask. What we actually ask for is 10 or 15 minutes *per year* to see if somebody is doing something outrageous that you need 
to check on.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Sep 2021 10:17:55 +1300

Hi Adrian,
On 26-Sep-21 09:36, Adrian Farrel wrote:
> Really? Why? This seems to totally deny the value of a new list. 

Possibly, but it's more friendly to people who are perfectly happy with the existing list.

> It is also not very pleasant in the context of the "mandatory subscription" described below because now people will get two copies of emails.

Not if you set the "no duplicates" option in mailman. I set it globally years ago and it improved my life considerably.

> Please don't do that. It is inertia subscription. That is not nice in my opinion.

I assume it would be an opt-out setting for new accounts. I think it's a reasonable strategy for existing accounts; how else will people know, because most of them aren't on ietf-announce?
 
> How about sending each Datatracker account registered email address an email offering them "click here to subscribe"?

Better, include a "click here to unsubscribe" at the end of the welcome message.
 
> This can be handled with a check box during account creation so that the account holder has the option.

... to opt out.

> Which is fine, but requires opt-out action which should not be the default.

I disagree. This isn't like a commercial advertising exercise; it's trying to get people to actually be members of our community.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Sep 2021 10:13:04 +0200

“All problems in computer science can be solved by another level of indirection”

— Butler Lampson

“All problems can be solved with an additional mailing list.” 

— The IESG

Below

> First, If we create an "important" list, will more people unsubscribe from the "announce" list? Is that the desired effect? If we do this experiment, will we monitor the "announce" list?

I vaguely recall -announce being created for important announcements. And now it seems that we have cluttered that list. A better approach would be to unclutter it.

Also, I don’t know about the rest of you, but there are so many IETF lists that I just dump them all into one folder, so this won’t make any difference to me, aside from mildly annoying duplicates that my UA really should do a better job at handling.

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 26 Sep 2021 13:26:51 +0000

*   I vaguely recall -announce being created for important announcements. And now it seems that we have cluttered that list. A better approach would be to unclutter it.

Strongly agree with this!

---

From: David Noveck <[email-masked]>
Date: Sun, 26 Sep 2021 10:32:01 -0400

I agree as well but it is hard to get agreement about what, specifically,
is clutter and what is not.  That can easily turn into a non-terminating
discussion.

In order to provide the desirable uncluttering, without getting into a
discussion about what people consider clutter, I propose that we extend
Lars's proposal and put each of the ten classes of items into its own list
so that we have ietf-announce-{news, charters, closures, new-lists,
new-rfcs, telechats, doc-actions, conflict-reviews, last-calls,
interim-meetings} allowing people to subscribe what they want to see
without getting what *they *consider clutter.

On Sun, Sep 26, 2021 at 9:28 AM Salz, Rich <rsalz=
[email-masked]> wrote:

>
>    - I vaguely recall -announce being created for important
>    announcements. And now it seems that we have cluttered that list. A better
>    approach would be to unclutter it.
>
>
>

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 26 Sep 2021 10:54:04 -0400

As someone who files ietf-announce into a folder because there are too many
messages, I feel most able to respond to this....

I propose the name be "ietf-announce-announce" because it tells me as a
consumer that "this is more important messages that must be read, rather
than the regular important messages like Yet Another interim for anima or
cbor (*)".

I do think that the whole focus on Datatracker accounts is really the wrong
way to look at engagement.

tim

(*) no offenses to anima or cbor working groups, they do fine work.

On Sat, Sep 25, 2021 at 12:03 PM Bob Hinden <[email-masked]> wrote:

> Like what Brian and other have said, 4.6 emails per workday doesn’t seem
> like a burden to me.  BTW, assuming “workday” means Monday-Friday, it’s
> only 3.3 emails per day over a year.
>
> Please break this down further.   That is, how many emails of each type
> per year.  It’s hard to evaluate this proposal without knowing that.
>
> This is disturbing.   How can one function in the IETF when you aren’t
> getting information about meetings, draft deadlines, new working groups,
> BOFs, etc.?
>
> How many of these data tracker accounts are active?    I wouldn’t be
> surprised that a large portion of them haven’t been used for a while, or
> sent email, etc.
>
>
> How many "automatically-generated Datatracker email” are there?  Are all
> except for 1. in the numbered lists data tracker generated?
>
> >

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 26 Sep 2021 16:24:09 +0100

> without getting what *they *consider clutter.

If that would happen, then I wouldn't subscribe to them simply because the
UX is terrible and the act of subscribing/unsubscribing is entirely
tedious. Seriously, do I need to confirm the same email address *every*
time I want to subscribe.

Cheers,
Lucas

---

From: "John Levine" <[email-masked]>
Date: 26 Sep 2021 11:33:28 -0400

>without getting what *they *consider clutter.

Ugh.  That's what mailman subject tags are for.

R's,
John

PS: I am also baffled that anyone with the technical skill to help write
IETF standards documents would find the current mail volume to be a problem.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 26 Sep 2021 11:50:13 -0400

> notwithstanding, had no real familiarity with the subject matter.)
<snip>

Ned leaves out one of the main causes of hostility which was the game of
trying to force group X to do the job of creating a reason to make use of
the work product of group Y.

There are still people in the DNS world who believe that creating new
resource records is the way to solve problems. And the people with real
world experience of getting records deployed can assure them it is not. It
took me over a decade to get CAA adopted and that and SRV are the only two
widely supported extensions to the DNS canon since IPv6.

Cross area review is hard because most of the areas have already become far
more complex than most people can understand on their own. There are very
few people who are comfortable with complexity and it is very common to see
people demanding simplification of the requirements as a gating condition
to start work. Which then leads to people pointing out that a show stopper
requirement has been ignored when the drafts reach last call.

In the days when people met in person, there was the idea that merely
having all the areas meet in the same time and place would cause expertise
to cross over through some sort of osmotic process. I don't think it did.

There is also the issue of gatekeeping and ring kissing. Very few areas are
interested in collaboration except on very specific terms.

If we are going to get anywhere with cross area, we are going to need to
approach the problem in a different way. I have not considered routing
since my undergraduate thesis and that was message routing within a MIMD
computer system. So there is information I really would like to know in
order to be able to understand BGP security. Specifically, by what
processes are bad routes detected and eliminated?

Nobody seems to want to tell me which suggests I might be correct in
suspecting the answer is that they aren't and we have open loop control.
The routing layer seems to be assuming that this is handled at the
transport layer but if you look at how TCP works, that obviously can't
happen.

The current system isn't working. If we want to have cross area
collaboration, we have to address that as an end in itself. The IAB
technical plenaries once played this role but that was probably the wrong
forum.

What would probably work better would be for the IAB to ask experts in the
various areas to produce presentations that tell people in other areas what
they need to know. Since we are working remote these days and likely
through 2023, podcasts are probably the ideal medium. This could be
followed by a discussion session,

Here is my contribution to the effort, a complete intro to the current
canon of cryptography:

Covid Cryptography - YouTube
<https://www.youtube.com/playlist?list=PLK2hHAOxepEjzZy3e71vEEPIEh7nKbPq8>
https://www.youtube.com/playlist?list=PLK2hHAOxepEjzZy3e71vEEPIEh7nKbPq8

That is probably at a more basic level than most folk in IETF would be
interested in. The successor course covering threshold cryptography is
probably more interesting. I will be releasing that fairly soon.

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Sep 2021 13:14:00 -0400

--On Sunday, 26 September, 2021 10:13 +0200 Eliot Lear
<[email-masked]> wrote:

> "All problems in computer science can be solved by another
> level of indirection"
> 
> — Butler Lampson
> 
> "All problems can be solved with an additional mailing
> list." 
> 
> — The IESG
> 
> Below
> 
>> First, If we create an "important" list, will more people
>> unsubscribe from the "announce" list? Is that the desired
>> effect? If we do this experiment, will we monitor the
>> "announce" list?
> 
> I vaguely recall -announce being created for important
> announcements. And now it seems that we have cluttered that
> list. A better approach would be to unclutter it.

Indeed.

Let me suggest one small example:  When a WG decides to schedule
an interim meeting, that announcement should go to the WG list
and _maybe_ to an Area-wide list for the relevant area, not to
IETF-announce.  Posting a calendar of upcoming meetings to
IETF-announce every month or so would seem reasonable even
though most of us know where to find that.

I also hope that most of us have at least half-competent MUAs
with either decent filtering capabilities, have gotten really
good at finding and hitting the "delete" key, or both.  Being
more careful about the design of subject lines for automated
announcements would help a lot with clutter management.  For
example, organizing subject lines something like

   Virtual meeting: <Area> <WG> <date and time info>

would make it _much_ easier to filter things according to
personal needs and inclinations than the current setup.  We
could also get better at dealing with the "only interested in
one class of things" issue that Bron identified by thinking
enough about metadata and categories enough that he (and I) are
put at least risk of missing something that is really important
to us because, for example, a decision was made many years ago
that work related to the DNS was an Internet Area issue rather
than an applications one and that work on email encryption was
about Security and not email: in both cases much of it quite
reasonably is, but some things aren't.  

So, while some tuning of the mailing lists may be appropriate,
let's put more energy, as Eliot suggests, into reducing clutter
rather than spreading it around.  And let's try to improve
information accessibility and the ability of people to
selectively get the information they need and manage it while we
are doing that.

Finally, I don't share Ned's pessimism (at least one most days)
and continue to believe that we should not make it extra-easy
for people to narrowly focus on one specific topic or set of
documents and ignore everything else.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Sep 2021 09:22:22 +1300

> “All problems can be solved with an additional mailing list.” 

“The correct amount of information flow to a group from its chairs/leaders
is a delta function” (i.e. a finite amount but in an infinitely narrow peak)

 — François Fluckiger

> Strongly agree with this!

I still don't get how 3.6 messages/day is "clutter".

I-D-announce@ is clutter. last-call@ is clutter.

A separate tracker-announce@ list might be helpful. As John Klensin suggests, interim meeting announcements could also be split out (but iirc, there is a rule that they MUST be announced).

However, it can all be sorted automatically by any decent user agent.

On 27-Sep-21 04:33, John Levine wrote:
> That's what mailman subject tags are for.

Exactly. Problem solved.

   Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 26 Sep 2021 17:03:09 -0500

Should I chime in? Oh, why not. I'm only chatting about one part of Ned's
note ...

On Sat, Sep 25, 2021 at 9:02 AM <[email-masked]> wrote:

> * But no matter how much any of may dislike the present situation, we are
> where we are. *As it happens I think we are focusing on the wrong problem
> here (more

I don't think anyone can deny that we are where we are, so let's start
there. Are we good with where we are, or is it worth some of us spending
cycles thinking about how an organization made up of smart volunteers
working on a broad range of somewhat interrelated topics can be better?

If some of us

   - think good cross-area review, or even communication, is important, and
   - whatever is happening now isn't sufficient to continue to provide
   better cross-area awareness/understanding/communication/review than other
   SDOs which may not have any cross-area approval step between (using our
   terminology) the working group approving a document, possibly an area
   approving it, and it being published,

What should that subset of us do, to try to make things better?

There are things we've tried in the past, and it might be useful for some
of us who remember (for instance)
https://datatracker.ietf.org/wg/icar/about/, which was IIRC focused on
cross-area reviews, and the much more recent "technology deep dives" (for
example, https://datatracker.ietf.org/wg/wgtlgo/about/), which *I* intended
as ways to get (for the first one, people from routing, the internet area,
transport, and ops) into the same room, and talk about how something that
one area specifies, and other areas make decisions that affect how useful
the "something" is.

It might also be useful for some of us to think about what we haven't tried
yet (and I might suggest having a conversation about whether we should
focus on cross-area awareness, understanding, communication, or review, as
a starting point.

And those are, of course, only my opinions. Perhaps other people might have
other helpful suggestions about what we should do?

The green flag drops, and they're off ... maybe ,,,

Best,

Spencer

---

From: tom petch <[email-masked]>
Date: Mon, 27 Sep 2021 09:37:29 +0100

> How about sending each Datatracker account registered email address an email offering them "click here to subscribe"?

No, because there is nothing to click in plain text and anyone using 
html is inviting breaches of security.

Tom Petch

> .

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Sep 2021 12:10:20 +0300

Hi,

thanks for the feedback!

> subscribers, for example), drop it.

we'll take that into consideration.

> 2. Make it opt-out for meeting registrants. Ideally, it would also be opt-out for anyone who subscribes to any IETF list whatever, but I don't know if that's practicable.

I'm not quite sure I understand what you mean by "make it opt-out" - do you mean "subscribe by default"?

FWIW, registration to a meeting has for some time now required creation of a Datatracker account, so the proposal would already cause meeting registrants to be subscribed to important-news.

I personally think that subscribing anyone that is on any IETF mailing list (IIRC that is ~45K people) to important news is pushing things too far. But we could maybe defined what we'd consider an "active participant" to be, and discuss subscribing those? Maybe "has attended at least one of the last X meetings, or sent at last Y emails to IETF lists over the last Z years"?

> *not* in the WG concerned. In fact, this would amount to an end-run around RFC2026, for standards track and BCP drafts.

There is no intention of classifying such emails as unimportant, and RFC2026 requiring use of ietf-announce is one reason why we decided to leave that list untouched.

But sending something to ietf-announce is not achieving and probably has never achieved the goal of disseminating "to everybody", even around the time RFC2026 was written. ietf-announce has only ever reached the fraction of the community that had an active interest in receiving the disseminated content, and that fraction seems to have become quite small. This is causing real problems in many areas, for example, with announcing NomCom-related information.

I disagree that creation of a new mailing list can be seen as somehow in conflict with RFC2026 when ietf-announce would continue to operate as it has.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Sep 2021 13:40:49 +0300

Hi,

thanks for the feedback!

> Like what Brian and other have said, 4.6 emails per workday doesn’t seem like a burden to me.  BTW, assuming “workday” means Monday-Friday, it’s only 3.3 emails per day over a year.

Correct. While that amount of email is OK to some, it seems to not be OK for others. And participants in the latter group seem to unsubscribe rather investing the time to tweak their filters, which is their choice.

> Please break this down further.   That is, how many emails of each type per year.  It’s hard to evaluate this proposal without knowing that.

OK, this is based on the monthly ietf-announce mbox files, starting with 2020-10.mail, so the counts are slightly different than in the original email. I did this manually with tags in mutt, so take this with a grain of salt:

1196 total messages

1.  Announcements sent manually
	34	by the IETF Chair/ED
	39	the IAB Chair
	0	the IRTF Chair
	0 	the Chair of the LLC Board
	136	the IETF Executive Director
	20	the NomCom Chair
	13	the IETF Tools support
	3	IANA
	1	ISOC
	38	and the IETF Secretariat
2.  Announcements of new and updated WG charters
	44
3.  WG closure announcements
	(included in above 44)
4.  Announcements of new non-WG mailing lists
	13
5.  Announcements of new RFCs
	275
6.  IESG and LLC telechat announcements
	39
7.  Announcements of document actions
	175
8.  Announcements of IESG conflict-review results
	14
9.  Last call announcements for I-Ds
	174 (+ 4 for other actions)
10. Interim WG meeting announcements
	256

> How many of these data tracker accounts are active?    I wouldn’t be surprised that a large portion of them haven’t been used for a while, or sent email, etc.

I don't have that data, but I will ask. See my response to Brian on that we maybe want to come to agreement on a definition of an "active participant", for these and other reasons.

> How many "automatically-generated Datatracker email” are there?  Are all except for 1. in the numbered lists data tracker generated?

Everything in my list above except those under (1) are automatically-generated. Roughly 1000.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Sep 2021 13:49:47 +0300

Hi,

thanks for the feedback!

On 2021-9-25, at 20:59, Christian Huitema <[email-masked]> wrote:
> The problem is that if most of those emails feel like noise, the receivers will most likely filter the mailing list and either ignore it all or put it in some folder for "view that when I have time". Noisy mailing lists get ignored, or just not subscribed.

or, given that many MUAs now offer one-click unsubscriptions, they unsubscribe if the first few messages seem irrelevant to them.

> First, If we create an "important" list, will more people unsubscribe from the "announce" list? Is that the desired effect? If we do this experiment, will we monitor the "announce" list?

That's of course not the desired effect, and your suggestion to monitor the ietf-announce list is a good one. My personal belief is that people who are subscribed to ietf-announce see the value and would hence not unsubscribe, but that we might reach some of those people who are at the moment not subscribing to ietf-announce with a more focused list.

> Second, who exactly defines what is important?

The current proposal is that important-news would have all manual postings by the various organizational roles, i.e., everything under (1):

We would ask those posters to determine on a case-by-case basis whether a given announcement meets their bar for important-news or nor.

>  Is that another way to empower people in elected positions, relative to the average participant?

I'm not sure I follow. The "average participant" cannot post to ietf-announce now, and they wouldn't be able to post to important-news either. That ability was always restricted to certain org roles?

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Sep 2021 13:55:49 +0300

Hi,

thanks for the feedback!

> Really? Why? This seems to totally deny the value of a new list. It is also not very pleasant in the context of the "mandatory subscription" described below because now people will get two copies o…

The value of the new list is in hopefully reaching IETF participants who choose not to subscribe to ietf-announce.

I do see your point about two copies of emails. We'll discuss if that can be addressed.

> Which is fine, but requires opt-out action which should not be the default.

On the points above, we'll discuss more if opt-in or opt-out should be the default.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Sep 2021 13:59:24 +0300

Hi,

thanks for the feedback!

> I vaguely recall -announce being created for important announcements. And now it seems that we have cluttered that list. A better approach would be to unclutter it.

we discussed that (at length) in the IESG. There were very different opinions on which content should remain on ietf-announce and which should be moved elsewhere. I think I've seen signs in the feedback thread that there are probably very different views on that in the broader community as well. Hence the decision to propose a new mailing list.

Thanks,
Lars

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Sep 2021 17:36:15 +0200

Hi Lars,

I'm sorry, but this is a corollary to Housley's Law, which borrows from 
many, including Benjamin Franklin:

    I have already made this paper too long, for which I must crave
    pardon, not having now time to make it shorter.

In an admirable effort to be transparent, we have inundated this list in 
particular with data.  We now need to take the time to reduce that data  
to usable information.  Please take another swing.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Sep 2021 12:59:49 -0400

I don't specifically object to this proposal.   And I concur with the 
observation that automatically-generated mail lowers the signal-to-noise 
ratio of the IETF-announce list.   Actually I believe this is true of 
email in general - it's not just spam that's the problem, it's that 
email has become the favorite dumping ground for lots of 
automatically-generated low-value information.

But I do find myself wondering whether dividing up the IETF discussion 
into an increasing number of increasingly narrow silos, is really in the 
best interests of the IETF or the Internet.   Or if every time we see 
that the signal-to-noise ratio on a particular list is too low, the 
right answer is always to narrow the topic, without considering anything 
alternatives.   We've been doing that for decades now and I can't tell 
that it's improved things.   If anything, it seems like we've lost a 
sense of community and common purpose that the [email-masked] list used 
to provide (even acknowledging the problems with it).

Keith

---

From: Christian Huitema <[email-masked]>
Date: Mon, 27 Sep 2021 11:46:24 -0700

> We would ask those posters to determine on a case-by-case basis whether a given announcement meets their bar for important-news or nor.

As I wrote before, a lot of those belong to something like "a log of the 
IETF". I think this would be better treated as publishing a log on an 
IETF web page, with possibly a weekly or monthly reminder.

> I'm not sure I follow. The "average participant" cannot post to ietf-announce now, and they wouldn't be able to post to important-news either. That ability was always restricted to certain org role…

You are right. But I am still concerned with the asymmetry of sending 
data through one-way lists. Take two recent messages on the 
ietf-announce list:

1) Reminder: IETF 112 Birds of a Feather (BOF) proposals due by 10 September
2) Proposed Experiment for IETF 112: Moving the Plenary

The first one clearly belongs in some kind of "log of events" category. 
Having that sent to a one-way list like "ietf-announce" makes sense -- 
although I would still prefer handling that as a web page. The second 
one proposes an experiment and calls for comments. Both messages were 
sent to several mailing lists: ietf-announce with copies to 112all and 
ietf for the first one, ietf-announce with copies on wgchairs, 112all 
and ietf for the second.

That seems like message inflation, and I believe we would be better off 
with some simple rule. The send-only ietf-announce list looks right for 
the first message: it is an annoucement, no discussion is expected. On 
the other hand, if discussions are expected, it would be better to just 
send them on the list where those discussions are supposed to take place 
-- probably the IETF list. Unless the goal is to have parallel 
discussions on several different lists.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Sep 2021 09:05:04 +1300

Lars,
On 27-Sep-21 22:10, Lars Eggert wrote:
...
> I'm not quite sure I understand what you mean by "make it opt-out" - do you mean "subscribe by default"?

I mean that on the web page where one signs up for the datatracker, or registers for a meeting,
there should be a *pre-ticked* box for "Join the [email-masked] mailing list". In fact, a list would be even better; thinking out loud:

[/] [email-masked]     -- important IETF announcements
[/] [email-masked] -- general IETF announcements
[/] [email-masked]          -- general discussion list
[/] agenda-announce        -- meeting announcements of all kinds
[/] last-call              -- IETF-wide document last calls
[/] I-D-annnounce          -- Internet Draft announcements
[/] rfc-announce           -- RFC announcements
[/] datatracker            -- general data tracker announcements

and maybe one or two more. 

And set "no duplicates" in mailman for all announcement lists.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Sep 2021 22:49:39 -0400

--On Tuesday, September 28, 2021 09:05 +1300 Brian E Carpenter
<[email-masked]> wrote:

>>> 2. Make it opt-out for meeting registrants. Ideally, it
>>> would also be opt-out for anyone who subscribes to any IETF
>>> list whatever, but I don't know if that's practicable.
>> 
>> I'm not quite sure I understand what you mean by "make it
>> opt-out" - do you mean "subscribe by default"?
> 
> I mean that on the web page where one signs up for the
> datatracker, or registers for a meeting, there should be a
> *pre-ticked* box for "Join the [email-masked] mailing list". In
> fact, a list would be even better; thinking out loud:
> 

Brian, 

Whether opt-out or opt-in, such a list invites people to get
only the information they think they need and would mitigate
against finding out about (not necessarily tracking) things that
might be of interest, even within an Area or part of an Area.
Once one starts un-checking boxes, it is mechanically and
psychologically really easy to check many of them.

In addition, for those of us who do considerable local filtering
or message routing based on the list used and sometimes parts of
the Subject line, having Mailman apply "no duplicates" is a
truly horrendous idea, especially if we don't want to make a
trip to the bikeshed to discuss which list is preferred if a
message is posted to several of them and the particular user is
subscribed to all or those or a subset.  If we think the above
are discrete categories and people should be able to decide
which to subscribe to [1], then any announcement messages should
go to at most one of those lists and people who want to get that
type of announcement should subscribe.

FWIW, agenda-announce is an interesting case that illustrates
the problem. If I'm only interested in meeting announcements in
an Area or two (plus IETF-wide ones or not), it doesn't help me
at all.  To allow me to control that, I would need 
   IETF-meeting-announce
   ART-meeting-announce
   GEN-meeting-announce
   INT-meeting-announce
etc.

Or to carry that argument in the direction of the ridiculous, it
might be reasonable for me to want to follow the meeting
announcements and Last Calls from particular WGs while not
participating actively in their mailing list.  For a
hypothetical Foo WG, that might mean, instead of
[email-masked],

  Foo-meeting-announce
  Foo-last-call-announce
  Foo-discuss

while today, all of those are lumped together, with what would
be the first two copied to the third.... just like your list
above is all copied to/ merged into ietf-announce.

Conclusion: It is unlikely that one can tailor lists that
provide the right information, with no noise, to many IETF
participants.  If we want to help, we should put more energy
into trying to make it efficient for participants to read things
they are interested in and discard (manually or automatically)
the rest with minimal fuss.  But I think that has been said
before in other ways.

best,
   john

[1] My guess is that the categories are not as discrete as we
would like and that there will be edge cases... perhaps another
reason to not go down the "many list" plan or, if we must, to
not go very far down it.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Sep 2021 17:04:07 +1300

> psychologically really easy to check many of them.

That seems to vary wildly between people. I agree that it might
have unintended side effects.

> truly horrendous idea, 

Again, it depends and should be (indeed is) a personal choice
in mailman, with the current default being "off".

> especially if we don't want to make a

Well, that's exactly why I operate with "no duplicates" *on* and
sort incoming mail based on both the list names and the subject.
So really I don't care how many different announce lists there are,
they all get treated the same. But that's me, and you do it differently.
There's no perfect solution.

> the rest with minimal fuss.  But I think that has been said

And actually I completely agree with that conclusion. Whatever
the IESG decides in this case, I will make a small adjustment
to my subscriptions and incoming mail filters, but nothing
much will change in my workflow.

Regards
   Brian

> reason to not go down the "many list" plan or, if we must, to

[Agreed]

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 28 Sep 2021 16:42:39 +0200

I don't mind to having IESG to specify the important news that we MUST
know under their direction/management-responsibility, in any organisation
there are who listen and who ignore directions. Knowing the important
announcement from normal is always important for serious participants and
newcomers. I think this new list should be set by IESG each term (it should
change depending on new situations/policies).

Best wishes,
AB

---

From: Andrew Campling <[email-masked]>
Date: Tue, 28 Sep 2021 16:46:05 +0000

On Sun, Sep 26, 2021 at 23:03  Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:

> Should I chime in? Oh, why not. I'm only chatting about one part of Ned's note ...
>
> On Sat, Sep 25, 2021 at 9:02 AM <[email-masked]<mailto:[email-masked]>> wrote:

> I don't think anyone can deny that we are where we are, so let's start there. Are we good with where we are, or is it worth some of us spending cycles thinking about how an organization made up of smart volunteers working on a broad range of somewhat interrelated topics can be better?
>
> If some of us

  *   think good cross-area review, or even communication, is important, and
  *   whatever is happening now isn't sufficient to continue to provide better cross-area awareness/understanding/communication/review than other SDOs which may not have any cross-area approval step between (using our terminology) the working group approving a document, possibly an area approving it, and it being published,
> There are things we've tried in the past, and it might be useful for some of us who remember (for instance) https://datatracker.ietf.org/wg/icar/about/, which was IIRC focused on cross-area reviews, and the much more recent "technology deep dives" (for example, https://datatracker.ietf.org/wg/wgtlgo/about/), which *I* intended as ways to get (for the first one, people from routing, the internet area, transport, and ops) into the same room, and talk about how something that one area specifies, and other areas make decisions that affect how useful the "something" is.
>
> It might also be useful for some of us to think about what we haven't tried yet (and I might suggest having a conversation about whether we should focus on cross-area awareness, understanding, communication, or review, as a starting point.
>
> And those are, of course, only my opinions. Perhaps other people might have other helpful suggestions about what we should do?
>

If there is no agreement that cross-area working is important then a discussion about separating the IETF into multiple SDOs, one for each area, would seem to be a reasonable next step.  If however, there is consensus that cross-area working is important, perhaps alongside a greater focus on reinforcing the sense of community within the IETF, then it needs more action than the restructuring of some existing mailing lists and/or creation of some new ones.

So I agree with Spencer that further discussion is needed to agree on the right starting point before identifying solutions.  I’d add that this seems to me to be pretty important to the long-term health of the IETF as an organisation and simply focusing on mailing lists detracts from what should be a key activity.  [Fixing communications issues like mailing lists of course matters too but this can be addressed once the core problems are properly identified as part of a broader set of actions].  Others will no doubt have views on the best way to proceed within the appropriate IETF structures.

Andrew

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 29 Sep 2021 16:36:57 +1000

There were many places to hang this comment in this thread, but I'm going to hang here, because Eliot does make a very good point about too much noise.

I believe that there should be a list, it doesn't matter which one, to which every "participant" in the IETF is required to be subscribed.

What is sent to that list should be precisely the small subset of information it is considered absolutely necessary to know in order to participate meaningfully in the IETF.  That means it needs to be:
 * *timely* - if it's just for reference then the information should be clearly discoverable on the IETF website, not sent in an all-hands email.  There should be a time-related element for why people need to know it NOW.  "IETF 107 has been moved to online due to extenuating circumstances" is a good exemplar here.

either:

 * *a) new* - something about how the IETF operates has changed, and everybody needs to know.  Information such as "the RFC editor is now X", or "the Nomcom has appointed the following list of brave volunteers to the following roles" are good exemplars - knowing who to contact is important; or
 * *b) worthy of repeating* - this is the kind of key highlight that (for example) I give in my quarterly presentations to staff at Fastmail.  These are the key things you need to know to function, and here's where to look for more information.
   * I would even include a monthly email with the key dates in the next month under this heading, just because it provides reminders, and is worth repeating.
 * *succinct* - if 30,000 people are likely to read it, then it needs to just say the absolute minimum headline of "this is what you need to know, more information available at the following" and link to a page where more detail is available.  e.g. "The NOTE-WELL has been updated to require everybody to wear business-professional clothing at all meetings - new notewell here, dress-code document here".
 * *actionable *- reading this email should be enough for the person receiving it to understand whether they need to follow up and get more information.

The key goal should be that roughly-nobody (in the vein of rough consensus) feels that their time is wasted by reading emails to this list.  They SHOULD NOT (maybe even MUST NOT) be duplicates of full emails sent to other lists - they are the headlines of must-know information and pointers to more detail, that's all.

Other than totally urgent things on the order of an IETF being rescheduled, I would say that a maximum of one post per week should be enough traffic for this kind of list.

And yes, I would say that full-IETF surveys (up to a maximum of a quite small number per year) are reasonable to send to such a list.  The ability to survey your membership is very important to be able to serve them well and not just serve the loudest voices.

Regards,

Bron.

On Tue, Sep 28, 2021, at 01:36, Eliot Lear wrote:
> Hi Lars,
> 
> I'm sorry, but this is a corollary to Housley's Law, which borrows from many, including Benjamin Franklin:
> 
>> I have already made this paper too long, for which I must crave pardon, not having now time to make it shorter.
>> 
> In an admirable effort to be transparent, we have inundated this list in particular with data.  We now need to take the time to reduce that data  to usable information.  Please take another swing.
> 
> Eliot
> 
> *Attachments:*
>  * OpenPGP_signature

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Sep 2021 10:07:46 +0100

Bron Gondwana wrote on 29/09/2021 07:36:
> The key goal should be that roughly-nobody (in the vein of rough 
> consensus) feels that their time is wasted by reading emails to this 
> list.

One person's idea of what's important is not the same as another's.  The 
danger of throwing a bunch of stuff into a single feed labelled 
"important news" is that people will end up thinking "wait, I thought 
you said this was important but now I'm getting all these emails about 
$blah", where $blah is low on their priority list.

4.6 routine emails per day is low volume for most.  For others, 23 high 
priority emails a week will easily fall into 
straw-that-broke-the-camel's-back territory.

Nick

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Sep 2021 15:11:31 +0300

Hi,

> In an admirable effort to be transparent, we have inundated this list in particular with data.  We now need to take the time to reduce that data  to usable information.  Please take another swing.

the IESG certainly could. But I'm also pretty convinced that whatever proposal we came up with would get improved by the community pretty immediately.

So maybe we could try the opposite, and see if the community has some consensus on what information they would like to retain on ietf-announce, under the assumption that that would then remain our lists for broad announcements.

For reference, here's again the list of posting classes that currently go there, and the count of messages in each class in the last year:

1.  Announcements sent manually by <various roles> = 284
2.  Announcements of new and updated WG charters & WG closures = 44
3.  (included in above 44)
4.  Announcements of new non-WG mailing lists =	13
5.  Announcements of new RFCs =	275
6.  IESG and LLC telechat announcements = 39
7.  Announcements of document actions = 175
8.  Announcements of IESG conflict-review results = 14
9.  Last call announcements for I-Ds = 174 (+ 4 for other actions)
10. Interim WG meeting announcements = 256

The "important-news" proposal would only retain those under (1) above. (We could have a conversation if some of those could also be moved elsewhere, but that's maybe a separate discussion.)

For any type of posting we'd remove, we could of course create a new list, so that the information was still shared. I understand that when we move to mailman3, we'll get a much better web-based subscription interface that will make managing subscriptions much more straightforward.

Thanks,
Lars

---

From: "MORTON JR., AL" <[email-masked]>
Date: Wed, 29 Sep 2021 12:57:21 +0000

Hi Lars,

following-up on "reduce the data to usable information":

It occurred to me that when I see several separate (#10) Interim Meeting announcement e-mails for the *same* WG, that a consolidated announcement for all the meetings would suffice. (One press of the delete key for those who are uninterested.)

Then, any announcement that is purely an announcement (no e-mail discussion thread follows) could be combined with others (#4,6,7,8) when they are prepared/ready close in time.

We retain the same info on ietf-announce with fewer messages.

Al

> -----Original Message-----
> From: WGChairs <[email-masked]> On Behalf Of Lars Eggert
> Sent: Wednesday, September 29, 2021 8:12 AM
> To: Eliot Lear <[email-masked]>
> Cc: Working Chairs <[email-masked]>; Christian Huitema
> <[email-masked]>; IETF <[email-masked]>
> Subject: Re: Proposal: an "important-news" IETF announcement list
> 
> Hi,
> 
> particular with data.  We now need to take the time to reduce that data  to
> usable information.  Please take another swing.
> 
> the IESG certainly could. But I'm also pretty convinced that whatever proposal
> we came up with would get improved by the community pretty immediately.
> 
> So maybe we could try the opposite, and see if the community has some
> consensus on what information they would like to retain on ietf-announce,
> under the assumption that that would then remain our lists for broad
> announcements.
> 
> For reference, here's again the list of posting classes that currently go
> there, and the count of messages in each class in the last year:
> 
> The "important-news" proposal would only retain those under (1) above. (We
> could have a conversation if some of those could also be moved elsewhere, but
> that's maybe a separate discussion.)
> 
> For any type of posting we'd remove, we could of course create a new list, so
> that the information was still shared. I understand that when we move to
> mailman3, we'll get a much better web-based subscription interface that will
> make managing subscriptions much more straightforward.
> 
> Thanks,
> Lars

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Sep 2021 14:05:48 +0100

Hiya,

On 29/09/2021 13:11, Lars Eggert wrote:
> consensus on what information they would like to retain on
> ietf-announce, under the assumption that that would then remain our
> lists for broad announcements.

I don't consider the suggested new list worth the
effort. Nor would it be terrible.

I somewhat agree with those who worry about this
pattern: "subset of people have problem with list
traffic => correct answer is make new list and
split traffic between new and old lists."

A bit of de-duping and reducing the frequency of
announcing the now much more common interim meetings
would be good. (A weekly summary message of all
scheduled interims could be an option.)

Cheers,
S.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 29 Sep 2021 13:08:21 +0000

> For reference, here's again the list of posting classes that currently go there, and
> the count of messages in each class in the last year:
> 

I wonder... if 2 - 10 could all be sent to other list(s) and then a single weekly summary email sent to ietf-announce that has the list of subject lines with a link to the email in the archive.
This could even be done with a lot of emails from category 1.
Barbara

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Sep 2021 15:13:03 +0200

Hi Al,

I would go further, and consolidate all interim announcements into one 
per week on announce, and remind people to subscribe to the IETF 
calendar (WGs could still see the non-consolidated). Similarly 
consolidate document actions to one per week.  Similarly with RFCs.  
That reduces the #s considerably.

Eliot

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Sep 2021 15:17:53 +0200

> scheduled interims could be an option.)

I don’t need that, that’s what 

https://datatracker.ietf.org/meeting/upcoming

is for.

Much more interesting is the calendar integration (which now also exists).

The mail announcements usually have outdated information by the time I read them, so their net value is actually negative.

16 years ago, there used to be a way to do this kind of announcement properly (RFC 4287, if you don’t remember), but that seems to have fallen out of fashion…

Grüße, Carsten

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 29 Sep 2021 06:21:33 -0700

Maybe in the form of a weekly newsletter (email and RSS with full content), i.e. not just concatenation of messages and links, but classified by topics with a one sentence summary.

On 9/29/21 6:13 AM, Eliot Lear wrote:
> Hi Al,
> 
> I would go further, and consolidate all interim announcements into one per week on announce, and remind people to subscribe to the IETF calendar (WGs could still see the non-consolidated). Similarly consolidate document actions to one per week.  Similarly with RFCs. That reduces the #s considerably.
> 
> Eliot
> 

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Sep 2021 10:08:11 -0400

> The "important-news" proposal would only retain those under (1) above.

I think that 1, 4, and 6 should all be retained as is (and in the new
list, if it's created).

I think that 2, 5, 7, 8, 9, and 10 should be in a weekly summary, one
single message per week.

I think that when those under 10 are in a pattern (first Tuesdays,
every second Wednesday) there should be one message that says that,
and those messages should be immediately posted to the relevant
working group lists and not wait for the weekly summary.

If we do that, there's probably no need for a new list, but I don't
object to the new list.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Sep 2021 15:32:42 +0100

Hi Barry,

> I think that 2, 5, 7, 8, 9, and 10 should be in a weekly summary, one

I have a slight problem with this proposal because if it is implemented 
it would not be possible to find last call announcements by draft name. 
I think this is a rather important feature when searching archive.

Unfortunately I don't have a solution for this problem.

Best Regards,

Alexey

---

From: "MORTON JR., AL" <[email-masked]>
Date: Wed, 29 Sep 2021 14:49:06 +0000

> From: WGChairs <[email-masked]> On Behalf Of Alexey Melnikov
> Sent: Wednesday, September 29, 2021 10:33 AM
> To: Barry Leiba <[email-masked]>; Lars Eggert <[email-masked]>
> Cc: Working Chairs <[email-masked]>; IETF <[email-masked]>
[acm] 
Yes, any message that initiates an e-mail thread (like Last Call) should not be consolidated with other announcements. 
I was trying to avoid that with a smaller list for consolidation. Also, I have no problem seeing new RFCs announced individually, because it is the successful end of a long process for the authors, WGs usually celebrate these accomplishments, etc.

Al

---

From: Robert Sparks <[email-masked]>
Date: Wed, 29 Sep 2021 09:52:54 -0500

On 9/29/21 9:32 AM, Alexey Melnikov wrote:
> I have a slight problem with this proposal because if it is 
> implemented it would not be possible to find last call announcements 
> by draft name. I think this is a rather important feature when 
> searching archive.

This aspect - search for "thing" by looking for it in email Subject 
lines is what's driven so much of what people are now proposing to 
condense. Alexey points to a big use case - since people _reply_ to Last 
Call messages, searching for the subject is an easy way to find threads. 
Note the CCs on the Last Call messages currently going to IETF Announce.

Similarly, the "string of interims announcements" that was brought up is 
the way it is now because people _asked_ for one message per session 
that they could easily search for and easily visually scan for these 
(with the date) by subject. It started as one message. I'm happy to 
change this to whatever/wherever, but recognize that what's happening 
now was shaped by community feedback.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Sep 2021 11:07:00 -0400

> I think that 2, 5, 7, 8, 9, and 10 should be in a weekly summary, one

Mailman has a digest mode.  Would that suffice?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 29 Sep 2021 15:14:16 +0000

> Unfortunately I don't have a solution for this problem.

I thought we were discussing changes to ietf-announce and not last-call. All these emails already exist on the last-call list and don't need to be repeated in their entirety on ietf-announce. A summary email to ietf-announce should be sufficient. Anybody wanting to subscribe to last-call has the ability to do so. 
Barbara

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Sep 2021 11:33:55 -0400

--On Wednesday, September 29, 2021 09:52 -0500 Robert Sparks
<[email-masked]> wrote:

>...
> Similarly, the "string of interims announcements" that was
> brought up is the way it is now because people _asked_ for one
> message per session that they could easily search for and
> easily visually scan for these (with the date) by subject. It
> started as one message. I'm happy to change this to
> whatever/wherever, but recognize that what's happening now was
> shaped by community feedback.

Robert,

I think this is a perfect example of where more careful thinking
about the problem is important and where "more lists" are
perhaps just a distraction.  Probably this categorization is not
quite right two, but, for the interim announcements for a given
WG, I suggest that there are the following kinds of IETF
participants:

(1) Participants in the WG and (hence) subscribers to its
mailing list.
(2) People in the same area (small-"a") of work [1] who want to
track the WG but rarely, if ever, participate in any active way.
(3) People in other areas who might be curious about what is
going on.
(4) People who don't care whether that WG is meeting or not and
might prefer to not be told about it.

Now, for (1), separate, per-meeting, announcements might be just
right and, if people want them that way, they should continue to
go the per-WG mailing lists.  For (2) and (3) one announcement
for multiple interim meetings is likely just fine and that
announcement would be much more useful (and probably read more
often) if the announcement contained tentative agendas.  And,
for (4), the announcements are just noise, noise which those
people might prefer to have sent only to the unimportant-news
list to which almost no one would subscribe.

And, while I can't recommend either (partially because of the
tooling and complexity involved), the combination of groups (1)
and (2) are a case for either separate "announce" and
"discussion" lists for each WG or for being able to subscribe to
particular announcement postings based on metadata like topic
keywords, Area, and so on rather than treating these issues as
ones that can be solved by the rather blunt instrument of
fragmenting lists.

best,
    john

[1] This will often conform to our Areas, but not always, and
that is another issue.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Sep 2021 12:02:28 -0400

Exactly: the separate last call messages would continue to be posted
immediately to the last-call list, and the summary to ietf-announce would
serve as a reminder and as notice to those who don’t watch last-call
closely (or at all).

Barry

On Wed, Sep 29, 2021 at 11:14 AM STARK, BARBARA H <[email-masked]> wrote:

> I thought we were discussing changes to ietf-announce and not last-call.
> All these emails already exist on the last-call list and don't need to be
> repeated in their entirety on ietf-announce. A summary email to
> ietf-announce should be sufficient. Anybody wanting to subscribe to
> last-call has the ability to do so.
> Barbara
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Sep 2021 12:04:27 -0400

The problem with mailman digests is that you either get separate messages
or you get digests, and you can’t be more selective.  I don’t know whether
mailman 3 has more options in that regard.

Barry

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Sep 2021 12:05:45 -0400

--On Wednesday, September 29, 2021 10:08 -0400 Barry Leiba
<[email-masked]> wrote:

> I think that 1, 4, and 6 should all be retained as is (and in
> the new list, if it's created).
> 
> I think that 2, 5, 7, 8, 9, and 10 should be in a weekly
> summary, one single message per week.
> 
> I think that when those under 10 are in a pattern (first
> Tuesdays, every second Wednesday) there should be one message
> that says that, and those messages should be immediately
> posted to the relevant working group lists and not wait for
> the weekly summary.
> 
> If we do that, there's probably no need for a new list, but I
> don't object to the new list.

Barry, 

I generally agree, but wonder about 6 and 9 because...

6.  IESG and LLC telechats (especially the former) occur on a
fixed schedule (as much or more so than the subset of 10 you
mention) so, while links and exceptions may be important, the
announcements ought to be routine and part of a summary (and, as
others have suggested, an available and downloadable calendar).

9. There are problems with pushing Last Call announcements for
I-Ds, especially I-Ds proposed for standards track or BCP
action, into a weekly summary. We would, I think, like to
encourage people to watch those things and step in on ones on
which they might have informed opinions, even if, for a given
participant, such Last Calls are only a few percent of the total
and all of the others will be deleted after skimming the subject
line.  However, consider the timing.  If the Last Call is for a
WG document and announced to the WG list on, say, a Monday, the
digest does not appear until Friday, and first announcement
starts the clock, we've cut the time that interested participant
has to read the document and comment by almost half.  Different
permutations of dates just affect different people and documents
badly unless we make other changes.  I can think about ways
around that but most involve tinkering with timing of LC
announcements or which ones count -- these are not just matters
of creating new lists or shuffling content distribution.  Of
course, Alexey's concern about searching by draft name is a
different aspect of much the same problem.

That brings me close to Eliot's consolidation suggestion but is
also a reminder of what others have said -- that, inevitably,
different people are going to find different things important
and hence that efforts beyond a certain point to really
fine-tune things may be doomed.  I'm also confident we could
come up with a different list of categories of announcements:
probably not much better than the one Lars posted, but probably
not much worse either.  

If we can concentrate on improving the S/N ratio on the
Announcement list --selective digests, avoiding four separate
interim meeting postings at the same time for the same WG,
encouraging calendar subscriptions, etc.-- then I think we
address the real problem while splitting up lists even more just
create distractions.

best,
   john

---

From: tom petch <[email-masked]>
Date: Wed, 29 Sep 2021 17:16:34 +0100

Barbara

I think not.  Last Call announcements from the IESG go to many places 
but not the Last Call list.  I find this odd, raised it as a comment 
when the discussion about whether or not to persist with Last Call list 
but in vain.

Reply to is set to Last Call but that is all

Tom Petch

---

From: tom petch <[email-masked]>
Date: Wed, 29 Sep 2021 17:30:44 +0100

> The "important-news" proposal would only retain those under (1) above. (We could have a conversation if some of those could also be moved elsewhere, but that's maybe a separate discussion.)

I believe that it is a mistake to entitle something important; that is 
subjective, depends on the sender and is likely not true for the 
recipient.  Perhaps significant, noteworthy, you may be interested to 
know, anything that leaves the reader with his judgement unimpugned.

As to what, then I was thinking that the Admin announcements are the 
most irrelevant, except when they tell me of an impending outage, or one 
that just happened, or a possible one due to a migration.  These are 
rare but I would class them as Critical.

After that, Last Call announcements. A key feature of the IETF is 
cross-area review IMHO and the Last Call announcements make that point. 
  They could be summarised, since a last call is two weeks or more then 
a weekly e-mail of Last Call announcements made in the last seven days 
would cut the frequency by a factor of three on the IETF list with 
individual e-mails still going out on a not-so-significant IETF list.

After the, announcements about the creation or potential creation or 
winding up of a Working Group.  Again, working in Working Groups is a 
key feature of the IETF so they matter more.

Tom Petch

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Sep 2021 13:08:31 -0400

> mailman 3 has more options in that regard.

The setting is on a per-list basis.
Perhaps for the important-news, a default to weekly digest might appeal.
So if 2,3,5,7,8,9,10 was in a single list, then that would work?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Sep 2021 13:20:13 -0400

> address the real problem while splitting up lists even more just

On the topic of calendaring, and "upcoming" being more useful for planning.
I've asked for the various area meetings, such as the RTG Chairs Chat, IESG
telechat, IoT Directorate, etc. to be on the calendar.

My purpose is allow people who are planning meetings to know what else is
occuring.   Maybe we can do a "this week at the IETF" page.

There are tooling issues for some of these requests.
But, the major pushback I got was that some of these events are not open to
anyone, and so shouldn't be listed.  I disagree :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Sep 2021 10:12:57 +1300

> Mailman has a digest mode.  Would that suffice?

No, because from observation, most people who reply to a digest don't change the Subject to a useful string. This would be disastrous for Last Call workflows in particular.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Sep 2021 10:13:45 +1300

> I thought we were discussing changes to ietf-announce and not last-call. All these emails already exist on the last-call list and don't need to be repeated in their entirety on ietf-announce. A sum…

Unfortunately that doesn't compute. If someone sees the Last Call announcement on announce @ietf, they can simply reply and it will go where it needs to go. The whole point of last calls is they go to *everybody* so that *anybody* can reply. This is why I believe that Last Calls are possibly the most important content on announce@ and should definitely not be dropped.

I'm not against weekly summaries for most of the categories Lars listed, but I suggest that the model should be, for category X, that the raw messages go to [email-masked], and the summary comes labelled "X-announce messages for the week ending $DATE".

(And yes, I know there would be complaints about too many summary messages. Or too few.)

   Brian

---

From: Jay Daley <[email-masked]>
Date: Thu, 30 Sep 2021 11:28:54 +1300

> On 30/09/2021, at 10:13 AM, Brian E Carpenter <[email-masked]> wrote:
> 

I don’t mean to pick on you, but your use of the word "everybody" highlights what I see as  two huge misconceptions that are affecting this discussion.  

The first is the misconception that ietf-announce reaches, approximately reaches, or could theoretically reach the entire IETF community.  It currently reaches a small fraction of the community (somewhere between 5-10% depending on how we define the community) and all the evidence is that it will never reach even 25% because they don’t want all those emails.

The second is the misconception of just how much we can create an engaged community by pushing messages at them.  The experience from every organisation I have ever seen try this is that it’s a Pareto distribution and if you want a list that reaches everybody then it must receive virtually no messages at all otherwise people unsubscribe in such numbers that it rapidly drops below any usable approximation of everybody.

So far, I’ve heard the following broad reasons for not breaking up ietf-announce into multiple lists:

a) a detrimental effect on the process of subscribing to and managing subscription to multiple lists
b) a detrimental effect on reading/searching/finding email once those messages have been received
c) a detrimental effect on understanding what message is important and what is not and making sure nothing important is missed
d) a view that separate lists reduces overall engagement
e) a view that separate lists reduce cross-area discussion

I understand a) and c) - we need a much better interface for managing subscriptions to 100+ lists that also helps us understand the subject matter, volume and perceived importance of any list as well as what other lists are related.

For b), d) and e), while list organisation plays a part, in most practical situations there are other factors that are much more important.

Jay

> 
> I'm not against weekly summaries for most of the categories Lars listed, but I suggest that the model should be, for category X, that the raw messages go to [email-masked] <mailto:[email-masked]>, and the summary comes labelled "X-announce messages for the week ending $DATE".
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Sep 2021 11:49:47 +1300

On 30-Sep-21 11:28, Jay Daley wrote:
> 
> 
>> On 30/09/2021, at 10:13 AM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Unfortunately that doesn't compute. If someone sees the Last Call announcement on announce @ietf, they can simply reply and it will go where it 
needs to go. The whole point of last calls is they go to *everybody* so that *anybody* can reply. This is why I believe that Last Calls are possibly the most important content on announce@ and should definitely not be dropped.
> I don’t mean to pick on you, but your use of the word "everybody" highlights what I see as  two huge misconceptions that are affecting this discussion.

No worries, I don't feel picked upon.

> The first is the misconception that ietf-announce reaches, approximately reaches, or could theoretically reach the entire IETF community.  It currently reaches a small fraction of the community (somewhere between 
5-10% depending on how we define the community) and all the evidence is that it will never reach even 25% because they don’t want all those emails.

Indeed. That's why I understand the goal of significantly reducing the list traffic.

> The second is the misconception of just how much we can create an engaged community by pushing messages at them.  The experience from every 
organisation I have ever seen try this is that it’s a Pareto distribution and if you want a list that reaches everybody then it must receive virtually no messages at all otherwise people unsubscribe in such numbers that it rapidly drops below any usable approximation of everybody.

Sure. (Nevertheless, the traffic on the announce list is so tiny compared 
to my daily spam load that it's very hard to perceive it as a problem.)

> So far, I’ve heard the following broad reasons for not breaking 
up ietf-announce into multiple lists:

I'm not arguing against that, when linked to weekly summary messages. I'm 
arguing that Last Call messages are of such importance to the standards-making goal of the IETF that we really do have to send them to as much of the community as we can.
 
> For b), d) and e), while list organisation plays a part, in most practical situations there are other factors that are much more important.

Yes.
   Brian
    
> [email-masked] <mailto:[email-masked]>
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Sep 2021 19:07:40 -0400

> I'm arguing that Last Call messages are of such importance to the
> standards-making goal of the IETF that we really do have to send them
> to as much of the community as we can.

The trouble with that is that if you really believe that and take it
completely, we would be posting last-call announcements to every mailing
list we have: all the WG lists, all the non-WG lists, all the lists that
remain from closed groups, and whatever else.  I think few of us would like
that.

If my last sentence is correct, then we really do have to understand that
it’s more important to make sure that participants understand the
importance of last call and where to find the last-call announcements… and
then leave it to the community to do what they’re willing to do with that.
And that does not meal trying to force those announcements on people who
don’t want them.

It was different when the IETF was smaller.  We need to accept that things
have changed.

Barry

On Wed, Sep 29, 2021 at 6:50 PM Brian E Carpenter <
[email-masked]> wrote:

> >> On 30/09/2021, at 10:13 AM, Brian E Carpenter <
> [email-masked] <mailto:[email-masked]>> wrote:
> >>
> implemented
> >>> I thought we were discussing changes to ietf-announce and not
> last-call. All these emails already exist on the last-call list and don't
> need to be repeated in their entirety on ietf-announce. A summary email to
> >> Unfortunately that doesn't compute. If someone sees the Last Call
> announcement on announce @ietf, they can simply reply and it will go where
> it
> needs to go. The whole point of last calls is they go to *everybody* so
> that *anybody* can reply. This is why I believe that Last Calls are
> possibly the most important content on announce@ and should definitely
> not be dropped.
> >
> > I don’t mean to pick on you, but your use of the word "everybody"
> highlights what I see as  two huge misconceptions that are affecting this
> discussion.
>
> > The first is the misconception that ietf-announce reaches, approximately
> reaches, or could theoretically reach the entire IETF community.  It
> currently reaches a small fraction of the community (somewhere between
> 5-10% depending on how we define the community) and all the evidence is
> that it will never reach even 25% because they don’t want all those emails.
>
> > The second is the misconception of just how much we can create an
> engaged community by pushing messages at them.  The experience from every
> organisation I have ever seen try this is that it’s a Pareto distribution
> and if you want a list that reaches everybody then it must receive
> virtually no messages at all otherwise people unsubscribe in such numbers
> that it rapidly drops below any usable approximation of everybody.
>
> arguing that Last Call messages are of such importance to the
> standards-making goal of the IETF that we really do have to send them to as
> much of the community as we can.
>
> > c) a detrimental effect on understanding what message is important and
> what is not and making sure nothing important is missed
> > I understand a) and c) - we need a much better interface for managing
> subscriptions to 100+ lists that also helps us understand the subject
> matter, volume and perceived importance of any list as well as what other
> lists are related.
> >
> > For b), d) and e), while list organisation plays a part, in most
> practical situations there are other factors that are much more important.
>
> Yes.
>    Brian
>
> >
> > Jay
> >
> >
> >>
> >> I'm not against weekly summaries for most of the categories Lars
> listed, but I suggest that the model should be, for category X, that the
> raw messages go to [email-masked] <mailto:[email-masked]>, and
> the summary comes labelled "X-announce messages for the week ending $DATE".
> >>

---

From: Jay Daley <[email-masked]>
Date: Thu, 30 Sep 2021 12:17:06 +1300

> On 30/09/2021, at 11:49 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> 

I think you are still misunderstanding how this works.  

No matter what we do, we cannot change the inherent level of interest that people have in particular categories of messages.  If we push messages to people for which they have a low level of interest then they adapt their behaviour in response and we cannot stop that.  Generally this means unsubscribing, not reading specific messages, or simply becoming frustrated, and the more messages they are not interested in they receive, then the more they do that.  

This means that  we simply cannot tell how much that happens with any reliability and so with a list many different types of message we end up mistaking X subscribers to a list as X readers of each message sent to it, when the reality could be quite different.

By contrast, if we separate out those categories and people choose to subscribe then we get closer to X subscribers = X readers, correctly reflecting the inherent level of interest in those messages and minimising the message avoidance behaviours above.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 30 Sep 2021 09:40:31 +1000

On Thu, Sep 30, 2021, at 09:17, Jay Daley wrote:
> No matter what we do, we cannot change the inherent level of interest 
> that people have in particular categories of messages.  

What Jay said.

I subscribe to these lists, but deliberately ignore all traffic from them unless some other event causes me to search for a message.  I might not immediately mark announcements as read and file them away to be ignored if a more targeted list existed.  (https://xkcd.com/1205/ says that if I can spend a few minutes setting up an ignore rule and save 30s per day deleting/ignoring emails, it's a BIG win.)

Indeed, I would almost look for a separate list for each of the 10 categories Lars identified on that basis.  Of course, subscribing to multiple lists in mailman is a huge pain, but we shouldn't let something that might easily be fixed decide what is right.

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Sep 2021 20:44:12 -0400

> ignore cost me about 600 seconds per year to glance at the message and hit the delete key. I can identify four drafts where I've sent comments in response to an IETF Last Call in the past year (not…

If I understand your points, I think you're both right.     Yes, having 
the potential for broad review is important.   But for most readers, 
most of the Last Call announcements are irrelevant. This makes it harder 
to see the Last Call announcements that matter to them.

If we could subscribe to only Last Call announcements for particular WGs 
and/or particular areas, maybe we would get more Last Call feedback and 
our documents would benefit from more community reviews.

It's also not clear to me that we really need to have each LC 
announcement in a separate email, or that all subscribers should see 
them in that form.

As a thought experiment, I could imagine an announce-AREA list where 
there is one such list for every area that would see Last Calls, new 
proposed groups, group charter messages, etc. Similarly, a announce-WG 
list for each WG, so that people could watch for LC announcements and 
meeting announcements from any particular WG.   Or, as I and others have 
suggested, let each user choose exactly which kinds of announcements 
they wish to get email about.

The point is, it's really not difficult to do a better job of informing 
our community of relevant events than we do.

(and for those who think we shouldn't be creating "bespoke" software, my 
response is that innovating with the Internet is actually IETF's core 
function, that eating our own dogfood keeps us honest, and we shouldn't 
leave this to Big Corporations.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Sep 2021 20:58:42 -0400

On 9/26/21 10:32 AM, David Noveck wrote:

> discussion about what people consider clutter, I propose that we 
> extend Lars's proposal and put each of the ten classes of items into 
> its own list so that we have ietf-announce-{news, charters, closures, 
> new-lists, new-rfcs, telechats, doc-actions, conflict-reviews, 
> last-calls, interim-meetings} allowing people to subscribe what they 
> want to see without getting what /they /consider clutter.

"It is tempting, if the only tool you have is a mailing list, to treat 
every new topic as if it required a separate mailing list."

At some point the number of topics/lists became so large that it's hard 
to make sure you're getting most of the content you want, while avoiding 
most of the content you don't want.

Over time, there also seems to be a tendency to add new content to each 
list, especially automatically generated content which is often low 
value information for most recipients.   And this results in calls for 
even more lists, and/or to split existing lists.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Sep 2021 14:00:15 +1300

On 30-Sep-21 12:07, Barry Leiba wrote:
> The trouble with that is that if you really believe that and take it completely, we would be posting last-call announcements to every mailing list we have: all the WG lists, all the non-WG lists, all the lists that remain from closed groups, and whatever else.  I think few of us would 
like that.
> 
> If my last sentence is correct, then we really do have to understand that it’s more important to make sure that participants understand the importance of last call and where to find the last-call announcements… and then leave it to the community to do what they’re willing to do with that.  And that does not meal trying to force those announcements on people who don’t want them.
> 
> It was different when the IETF was smaller.  We need to accept that things have changed.

Absolutely. But that's exactly why I'm banging on about last calls, because the IETF is bigger than it was in 1995 and because we have multiple silos. I'm all in favour of reducing mundane announcements, so that people actually see the ones from outside their silo that are not mundane.

How would it be if a year's tally looked like this?

1.  Announcements sent manually by <various roles> = 284
2.  Last call announcements for I-Ds = 174 (+ 4 for other actions)
3.  Weekly summaries of other announcements = 52

I make that a 60% reduction in traffic.

  Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Sep 2021 21:01:29 -0400

> IETF standards documents would find the current mail volume to be a problem.

I am baffled that anyone with the technical skill to help write IETF 
standards documents has enough extra time to deal with email that is, to 
them, irrelevant.   It seems to me that those skills are increasingly 
rare these days in proportion to the set of people developing Internet 
applications, and the relatively few people who have the depth and skill 
are often extremely busy.

Keith

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Sep 2021 21:31:34 -0400

--On Wednesday, September 29, 2021 20:44 -0400 Keith Moore
<[email-masked]> wrote:

>...
> As a thought experiment, I could imagine an announce-AREA list
> where there is one such list for every area that would see
> Last Calls, new proposed groups, group charter messages, etc.
> Similarly, a announce-WG list for each WG, so that people
> could watch for LC announcements and meeting announcements
> from any particular WG.   Or, as I and others have
> suggested, let each user choose exactly which kinds of
> announcements they wish to get email about.

Keith,

As I think I indicated in an earlier note, announce-AREA would
be a really good idea if it were not for the fact that the
binding of WGs to Areas is sometimes a bit arbitrary.   Perhaps
the most obvious example for the two of us is whether a
specification or WG looking at email security belongs in ART or
in SEC.  The answer is probably "yes", but specifications like
that are the ones that are most important to be carefully
reviewed in LC by people whose primary interests lie in the Area
to which the work was not assigned.

best,
  john

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Sep 2021 21:49:56 -0400

--On Wednesday, September 29, 2021 13:20 -0400 Michael
Richardson <[email-masked]> wrote:

>     > Announcement list --selective digests, avoiding four
> separate     > interim meeting postings at the same time for
> the same WG,     > encouraging calendar subscriptions, etc.--
> then I think we     > address the real problem while splitting
> up lists even more just     > create distractions.
> 
> On the topic of calendaring, and "upcoming" being more useful
> for planning. I've asked for the various area meetings, such
> as the RTG Chairs Chat, IESG telechat, IoT Directorate, etc.
> to be on the calendar.
> 
> My purpose is allow people who are planning meetings to know
> what else is occuring.   Maybe we can do a "this week at the
> IETF" page.
> 
> But, the major pushback I got was that some of these events
> are not open to anyone, and so shouldn't be listed.  I
> disagree :-)

I do too, for at least two reasons.  One is that transparency
suggests that we should not be secretive about which closed
meetings are being held.  The other, more important, is that
including the closed meetings makes it much easier for those who
might be involved in, or concerned about, them to spot potential
or actual conflicts.

  john

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Sep 2021 23:22:43 -0400

Sent from my iPhone

> On Sep 29, 2021, at 9:31 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> binding of WGs to Areas is sometimes a bit arbitrary.   

Agree, of course.  Area-specific announce lists would work well for some, but not all, perhaps not most, use cases.

A few minutes ago I was thinking that while it’s really easy to improve over what we’re currently doing, it’s probably difficult to make everybody, or even most participants, happy.

Keith

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Sep 2021 20:43:54 -0700

> might be involved in, or concerned about, them to spot potential

+1.

I think that the transparency of having closed meetings listed will also
cause people to reconsider if their meeting *really* has to be closed.

W

>   john
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 30 Sep 2021 20:10:30 +1000

> Absolutely. But that's exactly why I'm banging on about last calls, because the IETF is bigger than it was in 1995 and because we have multiple silos. I'm all in favour of reducing mundane announce…

Of course, this mailing list is already a self-selected subset of the IETF community (and even more subsetted after the dramas of $currentyear +/- N), and that's the subset who are happy to deal with mail volume.

So the only real way to find out what would be effective at communicating to with those who are NOT choosing to be on our current lists would be to survey a statistically viable number of them and find out!

My first suggestion would be to individually email a simple questionnaire to everybody who registers for IETF112 plus everybody who has posted a draft in the past year but is NOT on ietf-announce and ask them why they aren't out of a set of possible answers or "other".  But this suggestion is shooting from the hip.

What I do NOT think is of any real value is the high-email-volume-ophiles in this list making predictions, and I'm going to reluctantly lump myself into that group too - I've been extrapolating from the relatively small number of people I know who are in the "not on the announce list" category, and that's not good science.

Bron.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 30 Sep 2021 09:29:39 -0400

Indeed: very strong agreement from me with John and Warren.

Barry

On Wed, Sep 29, 2021 at 11:45 PM Warren Kumari <[email-masked]> wrote:
> I think that the transparency of having closed meetings listed will also cause people to reconsider if their meeting *really* has to be closed.
>
> W
>>
>>
>>   john
>>
> --

---

From: tom petch <[email-masked]>
Date: Thu, 30 Sep 2021 16:46:55 +0100

On 29/09/2021 17:30, tom petch wrote:
>>> In an admirable effort to be transparent, we have inundated this list
>>> in particular with data.  We now need to take the time to reduce that
>>> data  to usable information.  Please take another swing.
>>
>> the IESG certainly could. But I'm also pretty convinced that whatever
>> proposal we came up with would get improved by the community pretty
>> immediately.
>>
>> For reference, here's again the list of posting classes that currently
>> go there, and the count of messages in each class in the last year:
>>
>> (We could have a conversation if some of those could also be moved
>> elsewhere, but that's maybe a separate discussion.)

I said before that the e-mails of least general interest IMHO are those 
from the Director, which seem to make up almost half of category 1) most 
of which I see as being of little or no immediate concern.  The 
exception I made was for outages of our infrastructure, past, present 
and future, since I see those as bringing work to a grinding halt.

Yet today I see notice of an outage of a key part of our infrastructure 
on October 4th that has not been posted to ietf, ietf-announce or any 
such list AFAICT.

Weird.

Tom Petch

<snip>
> Tom Petch
>
>> For any type of posting we'd remove, we could of course create a new
>> list, so that the information was still shared. I understand that when
>> we move to mailman3, we'll get a much better web-based subscription
>> interface that will make managing subscriptions much more
>> straightforward.
>>
>> Thanks,
>> Lars
>>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Sep 2021 14:05:38 -0400

> No, because from observation, most people who reply to a digest don't
    > change the Subject to a useful string. This would be disastrous for
    > Last Call workflows in particular.

The categories proposed that would be on a list that would be digestable

>>>> 10. Interim WG meeting announcements = 256

So, we'd need to not include Last Call Announcements in that list.
Then would it work for you?

A thing that I like about the digest option is that the archives (and IMAP)
would have the individual messages.

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Sep 2021 15:05:18 -0400

On 9/26/21 1:14 PM, John C Klensin wrote:

> and_maybe_  to an Area-wide list for the relevant area, not to
> IETF-announce.

As much as I hate the excessive number of announcements, the problem I 
have with this idea is that the most important decisions tend to be made 
in interim meetings.   Interim meetings are sometimes used as a way to 
railroad decisions through WGs by making them "done deals" before they 
attract wider attention.

But of course the real problem isn't too many announcements, so much as 
over-use of interim meetings.   But burying announcements for interim 
meetings would seem to exacerbate that problem.  I think the principle 
that interim meetings are subject to the same rules for approval and 
announcement as other meetings, is the right principle.

Of course (especially in these pandemic days) interim meetings have 
arguably become the "normal" meetings, with the 3-per-year meetings 
becoming the odd ones.

Still, a periodic IETF-wide calendar that's sent to the list where 
meetings are announced, might be a good replacement for all of the 
current individual announcements.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Oct 2021 09:01:40 +1300

> Then would it work for you?

Not if it ever leads me to receive a message with a subject like

Re: document-actions Digest, Vol 52, Issue 41

That one would take many times longer before I could hit delete than

Re: Document Action: 'Boring Stuff' to Informational RFC (draft-ietf-boring-stuff-10.txt)
 
> would have the individual messages.

But in my experience people reply directly to the digest.

The bottom line is that people's workflows and email habits vary widely,
so there is no one-size-fits-all solution.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 30 Sep 2021 13:02:17 -0700

I haven’t been able to read all of the email in this discussion, but was thinking that except for "Announcements sent manually", everything else could be sent as a daily or weekly digest.   That way the volume of email would be reduced, we would not need a new list, and subscribers will receive all of this information.

The default for the Announce List could be a daily digest, but allow for changing it to weekly or individual emails.

If this has already been suggested, please treat it as a +1.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Oct 2021 09:12:15 +1300

>> and_maybe_  to an Area-wide list for the relevant area, not to

An interjection: that is a violation of the rule in RFC2026:

   For [sic] IETF and Working Group meetings announcements shall be made by
   electronic mail to the IETF Announce mailing list and shall be made
   sufficiently far in advance of the activity to permit all interested
   parties to effectively participate. 

Rules can be changed, of course,
 
> railroad decisions through WGs by making them "done deals" before they 

That's arguable. As we inevitably move towards less international travel
in the long run, I think we'll have to accept "interims" as the new normal.

> announcement as other meetings, is the right principle.

As noted, it's not a principle, it's a rule.

> current individual announcements.

Yes. Just another Updates: 2026.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Sep 2021 19:02:51 -0400

--On Thursday, September 30, 2021 15:05 -0400 Keith Moore
<[email-masked]> wrote:

>> Let me suggest one small example:  When a WG decides to
>> schedule an interim meeting, that announcement should go to
>> the WG list and_maybe_  to an Area-wide list for the relevant
>> area, not to IETF-announce.
> 
> As much as I hate the excessive number of announcements, the
> problem I have with this idea is that the most important
> decisions tend to be made in interim meetings.   Interim
> meetings are sometimes used as a way to railroad decisions
> through WGs by making them "done deals" before they attract
> wider attention.

Keith, noting Brian's comment about 2026 and adding to it that
making any important decision in a meeting of any sort rather
than on a mailing list violates other (IMO, even more important)
rules, my suggestion was based on an assumption that I'm
wondering if you share.  That assumption was that, if someone
was not following a WG to the extent of its being on its mailing
list, the odds of their seeing a schedule announcement for an
interim meeting of a particular WG and thereby deciding to
participate in that meeting are pretty low.  Not zero -- I've
done it myself as part of tracking a WG I'm concerned about but
don't have time to follow in-depth -- but rather low. And,
again, if we are really going to try to tune things by creating
lots of different mailing lists, that "want to keep an eye on
but not follow" behavior is an argument for announce-WG lists,
not for keeping all of those announcements for all WGs on the
main IETF-announce one.

> But of course the real problem isn't too many announcements,
> so much as over-use of interim meetings.   But burying
> announcements for interim meetings would seem to exacerbate
> that problem.  I think the principle that interim meetings
> are subject to the same rules for approval and announcement as
> other meetings, is the right principle.

Again, see Brian's comments.  However, the other principle, from
long before the pandemic, was to try to minimize interim
meetings in favor of encouraging working on mailing lists.  That
principle was established, IMO, because thoughtful emails
--rather than quick notes trying to simulate instant messages of
various sorts -- permitted and encouraged broader participation,
precisely because it made the discussions asynchronous and
immune from excluding people based on location.   I don't think
the pandemic caused the increase in the number of interims, but
it has certainly accelerated it.

> Of course (especially in these pandemic days) interim meetings
> have arguably become the "normal" meetings, with the
> 3-per-year meetings becoming the odd ones.

But therein lies, I think, the real issue.  If the new reality
is that we are rarely going to meet in person with a large
fraction of the most active and influential participants
present, it seems to me that we should be looking carefully at
all aspects of how we do things, not just trying to patch around
issues one at a time (as might be appropriate for problems and
changes we expect to last for a year or so (or a few meeting
cycles) followed by a return to "normal" (or at least status quo
ante).  And, if some of what is driving changes is just
evolutionary with the pandemic as a nasty coincidence, does that
make a difference or just make it a tad more important to ask
basic questions?

> Still, a periodic IETF-wide calendar that's sent to the list
> where meetings are announced, might be a good replacement for
> all of the current individual announcements.

Yes, especially if we continue, for multiple reasons including
those you have given, with individual announcements to relevant
WG mailing lists.    Coming back to Brian's comment about the
announcement requirement in 2026, today's question for
interested protocol lawyers is whether that language requires
individual per-meeting announcements or whether a combined
multi-meeting announcement (in calendar form and/or otherwise
would suffice to satisfy that requirement.  I note that, when we
announce an IETF meeting, we have never sent individual
announcements of each WG that intends to meet to IETF-announce.

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Sep 2021 20:06:07 -0400

On 9/30/21 7:02 PM, John C Klensin wrote:

> don't have time to follow in-depth -- but rather low.
I concur, at least to this point.
> And,

Perhaps, though I don't want to bikeshed too much about mailing list 
organization here.

The general picture that I'm seeing is that different people have 
different email reading habits, different ways of organizing email, etc. 
so that one size does not fit all.   I am therefore leaning toward a 
model of "let's make the data available in some well-documented easily 
parsed/filtered format say some combination of JSON, email headers, and 
plain text, and let participants use existing tools and/or build their 
own tools to maintain awareness of what they want to be aware of."    
Sure, pick some format that most people can deal with using popular mail 
readers or webmail clients.   As long as the metadata is in some 
well-defined parseable format,  the power users can probably get what 
they want anyway, and share their tools with others who want to try them.

>   I think the principle that interim meetings
> immune from excluding people based on location.

(applause)

I find conference calls (whether or not accompanied by video) to be 
vastly over-rated in terms of value returned per time/energy 
invested.    So in my mind there's no substitute for email, and IMO 
"interim" meetings should be used sparingly or in emergencies.   I 
realize that video calls are all the fashion these days, but they are 
maddeningly frustrating for discussions for lots of reasons that are 
technically very difficult to fix.

> issues one at a time

+1.

Keith