Subject: Re: [Gendispatch] Updating the IETF Discussion List Charter (was: Fwd: New Version Notification for draft-eggert-bcp45bis-02.txt)

From: Lars Eggert <[email-masked]>
Date: Mon, 12 Jul 2021 14:48:14 +0300

Hi,

coming back to this after my vacation - sorry for the silence.

On 2021-6-25, at 10:14, Mark Nottingham <[email-masked]> wrote:
> Looking at draft-nottingham-discussion-recharter again, I think there are a few things we could pull out and discuss as potential additions, without going as far as that draft suggests. For example:
> 
> - [ ] Reminding readers (including the IESG) that the list does not have all (or even a majority of) IETF participants subscribed, and so it is not appropriate to consider it as reaching the entire community. Along these lines, the current text about announcements being on ietf-announce@ should be strengthened, at least in the case of official announcements. I.e., it's not just a 'preference'.
> 
> - [ ] Clarifying language regarding when it's appropriate to move a discussion to another, more specific/appropriate list. Sometimes, people push back on this -- either because they want a larger audience, or they think the ietf@ is more sympathetic to their cause, for whatever reason. I think it would help if this scenario were specifically addressed.

I have no objection to these additions, especially if they come in the form of PRs :-)

I would like to see some indication from GENDISPATCH before merging though, to make sure that there is some level of consensus for them.

> I'd also hope that if we adjust this document, we'll also take the time to adjust the web site; right now, newcomers have no idea what the function of GENDISPATCH is (for example).

It might be helpful to add an appendix with some concrete proposed website changes to the document (to be removed on publication) that the website team can then translate into tickets.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 12 Jul 2021 14:55:07 +0300

Hi,

On 2021-6-26, at 0:05, Brian E Carpenter <[email-masked]> wrote:
> On 25-Jun-21 19:14, Mark Nottingham wrote:
> I find myself wondering whether ietf-announce should be an opt-out list. In other words, people who sign up for a meeting or at least one WG list should be subscribed to ietf-announce unless they decline. (Personally, I still don't understand how anyone who participates at all in the IETF can survive without the -announce list.)

there is some orthogonal discussion about revising ietf-announce, mostly by reducing the amount of automatically-generated email it gets (e.g., publication announcements of new RFCs, announcements of WG interim meetings, etc.)

Once that is in place, I think it would be more reasonable to automatically subscribe new (and existing?) participants to ietf-announce.

> The risk in overloading the newcomers info is that it becomes TL;DR. So my answer is a definite maybe. I did notice that https://www.ietf.org/about/participate/get-started/ doesn't have an obvious pointer to ietf-announce, for example. Adding that is another definite maybe.

I'm CC'ing Greg as the point person for the website. Please feel free to make concrete suggestions for website improvements to Greg and Jay?

Thanks,
Lars

---

From: Rob Sayre <[email-masked]>
Date: Mon, 12 Jul 2021 14:54:29 -0700

On Mon, Jul 12, 2021 at 4:48 AM Lars Eggert <[email-masked]> wrote:

> > Looking at draft-nottingham-discussion-recharter again, I think there
> are a few things we could pull out and discuss as potential additions,
> without going as far as that draft suggests. For example:
> >
> > - [ ] Reminding readers (including the IESG) that the list does not have
> all (or even a majority of) IETF participants subscribed, and so it is not
> appropriate to consider it as reaching the entire community. Along these
> lines, the current text about announcements being on ietf-announce@
> should be strengthened, at least in the case of official announcements.
> I.e., it's not just a 'preference'.
> >
> > - [ ] Clarifying language regarding when it's appropriate to move a
> discussion to another, more specific/appropriate list. Sometimes, people
> push back on this -- either because they want a larger audience, or they
> think the ietf@ is more sympathetic to their cause, for whatever reason.
> I think it would help if this scenario were specifically addressed.
>
> I would like to see some indication from GENDISPATCH before merging
> though, to make sure that there is some level of consensus for them.
>

Without having seen the concrete proposals, these two additions seem good
to me in the abstract.

thanks,
Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jul 2021 09:57:16 +1200

> there is some orthogonal discussion about revising ietf-announce, mostly by reducing the amount of automatically-generated email it gets (e.g., publication announcements of new RFCs, announcements…

But... but... but those are things that *should* be public. Taking I-D announcements off the ietf-announce list was fine, but each new RFC is a milestone. Interims are public meetings, explicitly open to anybody, not just people who happen to be on the WG list.

Truly, is the delete button so hard to find?

(I've used my delete button a lot today, because I'm on i-d-announce. But it's only a problem 3 days a year, when people rush to beat the cutoff.)

   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Jul 2021 15:50:13 -0700

On Mon, Jul 12, 2021 at 2:58 PM Brian E Carpenter <
[email-masked]> wrote:

> >>> - [ ] Reminding readers (including the IESG) that the list does not
> have all (or even a majority of) IETF participants subscribed, and so it is
> not appropriate to consider it as reaching the entire community. Along
> these lines, the current text about announcements being on ietf-announce@
> >> I find myself wondering whether ietf-announce should be an opt-out
> list. In other words, people who sign up for a meeting or at least one WG
> list should be subscribed to ietf-announce unless they decline.
> (Personally, I still don't understand how anyone who participates at all in
> the IETF can survive without the -announce list.)
> >
> > there is some orthogonal discussion about revising ietf-announce, mostly
> by reducing the amount of automatically-generated email it gets (e.g.,
> publication announcements of new RFCs, announcements of WG interim
> meetings, etc.)
>
> But... but... but those are things that *should* be public. Taking I-D
> announcements off the ietf-announce list was fine, but each new RFC is a
> milestone. Interims are public meetings, explicitly open to anybody, not
> just people who happen to be on the WG list.
>
> (I've used my delete button a lot today, because I'm on i-d-announce. But
> it's only a problem 3 days a year, when people rush to beat the cutoff.)

I certainly have sympathy for "ietf-announce" is too noisy, but I also
recognize that not everyone has the same preferences.

With that said, there's no reason to be locked into the "one-size-fits-all"
mailing list paradigm for this kind of automatic notification. Unlike ietf@,
the number of people who send mail to ietf-announce is very small, so we
don't really need to have it as a simple mailing list. Instead, what I
would suggest is that we modify the automatic notification system to allow
people to customize which notifications they want to receive (they can
still allo appear to go to the same list, which could even be called
ietf-announce if we want). That way, people can easily filter on the server
side and get just the subset they care about. [0]

-Ekr

[0] We can of course still build an archive that has every announcement.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Jul 2021 09:20:40 +1000

> On 13 Jul 2021, at 8:50 am, Eric Rescorla <[email-masked]> wrote:
> 

Somewhat relevant, courtesy of the newsclips service:
  https://www.nytimes.com/2021/07/10/business/gen-z-email.html

> I certainly have sympathy for "ietf-announce" is too noisy, but I also recognize that not everyone has the same preferences.
> 
> With that said, there's no reason to be locked into the "one-size-fits-all" mailing list paradigm for this kind of automatic notification. Unlike ietf@, the number of people who send mail to ietf-announce is very small, so we don't really need to have it as a simple mailing list. Instead, what I would suggest is that we modify the automatic notification system to allow people to customize which notifications they want to receive (they can still allo appear to go to the same list, which could even be called ietf-announce if we want). That way, people can easily filter on the server side and get just the subset they care about. [0]

That's a good idea. If we had such a system, we could also use it to produce things like RSS feeds, Slack channels, etc. so that people can choose how to consume the information.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Jul 2021 00:38:08 +0100

Hiya,

>    https://www.nytimes.com/2021/07/10/business/gen-z-email.html

I read that. It seemed to me to entirely ignore timezone
issues and others related to non-local collaboration. If
there're a non-email tools that do that well, it'd be good
to know.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Jul 2021 20:02:33 -0400

>   https://www.nytimes.com/2021/07/10/business/gen-z-email.html

Every single time someone suggests there is a user demand for something
better than SMTP email from the 1980s that hasn't changed since MIME, they
are aggressively patronized and told that there is absolutely no way that
the legacy system can ever, ever be replaced.

Perhaps it is time for more than a few of us to revise that particular
article of faith. Maybe the even younger generation is going to reject SMTP
the same way the then younger generation abandoned IRC for AOL instant
messenger in the 1990s.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jul 2021 14:42:55 +1200

> That's a good idea. If we had such a system, we could also use it to produce things like RSS feeds, Slack channels, etc. so that people can choose how to consume the information.

I agree. In other words, treat the distro lists as a back end, and if people prefer some kind of issue tracker tool, or RSS, or whatever, treat them as alternative back ends.

    Brian

---

From: Lars Eggert <[email-masked]>
Date: Tue, 13 Jul 2021 10:38:30 +0300

Hi,

On 2021-7-13, at 0:57, Brian E Carpenter <[email-masked]> wrote:
> But... but... but those are things that *should* be public.

and they will remain public. But we've seen feedback that one reason people don't subscribe or stay subscribed to ietf-announce is the bulk of such automated announcements they feel is not relevant to them.

> Taking I-D announcements off the ietf-announce list was fine, but each new RFC is a milestone.

Yes, but the population that is interested in being notified of every single RFC published is probably vanishingly small. And WG participants already receive them via the respective WG list, plus there is the dedicated https://www.rfc-editor.org/mailman/listinfo/rfc-dist mailing list.

> Interims are public meetings, explicitly open to anybody, not just people who happen to be on the WG list.

Of course. But so are regular WG meetings, and they don't get announced on ietf-announce individually, either. And interims are again already sent to the respective WG lists. They are also publicly announced at https://datatracker.ietf.org/meeting/upcoming and the related calendar file. If people prefer an email channel, a separate mailing list may be better than CC'ing ietf-announce?

> (I've used my delete button a lot today, because I'm on i-d-announce. But it's only a problem 3 days a year, when people rush to beat the cutoff.)

It may be a matter of work style. People have become used to more tailored notifications, and expect ietf-announce as a general announcement channel to only have the items that are of the broadest community interest.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 13 Jul 2021 10:42:01 +0300

Hi,

> [0] We can of course still build an archive that has every announcement.

I like this idea. Would this need to result in new custom datatracker code, or is there a third-party service that could be leveraged?

(This part of the discussion should also probably move to tools-discus.)

Thanks,
Lars

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 13 Jul 2021 05:51:09 -0700 (PDT)

> (This part of the discussion should also probably move to tools-discus.)

Lars, etc all,
	Isnt a majority of the issue on the one-size-fits-all front simply
the fact that several "sources" of email are aggregated onto the -announce
list, and the simple solution of creating a seperate list per source would
be in order, ie:
	ietf-announce-I-D-new		ONLY the announcements of new ID's
	ietf-announce-I-D-update	ONLY the announcement of updated ID's
	ietf-announce-general		Human created announcements
	...

	ietf-announce == All of the above

Thus a person could choose which ones they want to see, all the current
infustructures remains the same, sans 1 usually rather simple to implement
"forward" from each de-aggregated list to the aggregated list.

Thoughs on this solution?

Regards,
-- 
Rod Grimes                                                 [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 13 Jul 2021 16:14:29 -0400

It appears that Lars Eggert  <[email-masked]> said:
>> With that said, there's no reason to be locked into the "one-size-fits-all" mailing list paradigm for this kind of automatic notification. Unlike ietf@, the number of people
>who send mail to ietf-announce is very small, so we don't really need to have it as a simple mailing list. Instead, what I would suggest is that we modify the automatic
>notification system to allow people to customize which notifications they want to receive (they can still allo appear to go to the same list, which could even be called
>ietf-announce if we want). That way, people can easily filter on the server side and get just the subset they care about. [0]
>> 
>> -Ekr
>> 

You really, REALLY, do not want to try to reinvent a bulk mail system.

GNU Mailman has a little-used "topics" feature that I think can do the trick here.  The list manager configures
a set of topic regexps for the list, and subscribers can say which topics they want.  In each message the topic(s)
appear in the Subject or Keywords line and it sends the message to the people subscribed to the topics.  If you don't
pick any topics, by default you get all of them.

See https://www.gnu.org/software/mailman/mailman-member/node29.html

The interface within mailman to set the topics is pretty grody, but I presume it just puts stuff in the underlying
database so we could invent our own interface to it without extreme pain.

R's,
John

PS: Some of us don't subscribe to any IETF lists but instead retrieve the messages from the IMAP server, but I think we
can fend for ourselves.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jul 2021 17:43:36 -0400

The reason to not reinvent a bulk mail system is simple: It is a terrible
idea that has always sucked.

The Achilles heel of SMTP is that it is a push mode system. NNTP was better
because messages were pulled. An NNTP based discussion scheme would be a
much more effective way to manage 'mailing list' traffic because it is a
pull mode scheme.

The big mismatch between functionality and features here is that we are
trying to use SMTP as a workflow system which it is not what it is designed
to do.

A better solution would be an append only log of events such as ID
publication, RFC publication, interims, etc. that might trigger actions for
specific users and client software capable of processing those events on
the user's behalf according to rules specified by the user.

Sign the logs as a Merkle Tree and we have authenticated events and can do
more interesting stuff.

Of course, this is yet another of those 'things we could actually do with
crock-chain' which the crock-chain world completely ignores.

On Tue, Jul 13, 2021 at 4:14 PM John Levine <[email-masked]> wrote:

> >> With that said, there's no reason to be locked into the
> "one-size-fits-all" mailing list paradigm for this kind of automatic
> notification. Unlike ietf@, the number of people
> >who send mail to ietf-announce is very small, so we don't really need to
> have it as a simple mailing list. Instead, what I would suggest is that we
> modify the automatic
> >notification system to allow people to customize which notifications they
> want to receive (they can still allo appear to go to the same list, which
> could even be called
> >ietf-announce if we want). That way, people can easily filter on the
> server side and get just the subset they care about. [0]
> >>
> >> -Ekr
> >>
> >I like this idea. Would this need to result in new custom datatracker
> code, or is there a third-party service that could be leveraged?
> >
> appear in the Subject or Keywords line and it sends the message to the
> people subscribed to the topics.  If you don't
> The interface within mailman to set the topics is pretty grody, but I
> presume it just puts stuff in the underlying
> PS: Some of us don't subscribe to any IETF lists but instead retrieve the
> messages from the IMAP server, but I think we
> can fend for ourselves.
>
> --
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch
>

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2021 17:52:19 -0400

> much more effective way to manage 'mailing list' traffic because it is a

That's why I have an IMAP->NNTP gateway and read all the lists from my 
news server.  The threading and killfiles are nice, too.  But as you know, 
I am strange.

> Sign the logs as a Merkle Tree and we have authenticated events and can do

Unfortunately, decades of experience tell us that the reason we all still 
use e-mail is that it *is* a push system, the stuff shows up 
automatically, and we all still check our e-mail.  If we have to check 
some whizzo other thing, we won't, and it will fail.  The news hack works 
for me because I put every mailing list I read from everywhere into it, so 
it's only one place to look.

R's,
John

>> GNU Mailman has a little-used "topics" feature that I think can do the trick here.

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 Jul 2021 16:53:08 -0400

On 7/12/21 8:02 PM, Phillip Hallam-Baker wrote:

> On Mon, Jul 12, 2021 at 7:21 PM Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <https://www.nytimes.com/2021/07/10/business/gen-z-email.html>
>
>
> Every single time someone suggests there is a user demand for 
> something better than SMTP email from the 1980s that hasn't changed 
> since MIME, they are aggressively patronized and told that there is 
> absolutely no way that the legacy system can ever, ever be replaced.

On the contrary, email is constantly being replaced with facilities that 
are far less functional.     As far as I can tell, the biggest problem 
with email is that has become so widely used by everybody and everybot, 
that one's mailbox is typically full of low-value information.  (And 
while the delete key is not hard to find, there are so many low-value 
messages that simply selecting and deleting messages is a time-consuming 
chore, and every low-value message is a nuisance.   Also, not everyone 
deletes messages as they are read.)

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Jul 2021 18:12:01 -0400

On Fri, Jul 16, 2021 at 4:53 PM Keith Moore <[email-masked]>
wrote:

> are far less functional.     As far as I can tell, the biggest problem with
> email is that has become so widely used by everybody and everybot, that
> one's mailbox is typically full of low-value information.  (And while the
> delete key is not hard to find, there are so many low-value messages that
> simply selecting and deleting messages is a time-consuming chore, and every
> low-value message is a nuisance.   Also, not everyone deletes messages as
> they are read.)
>
The critical flaw in all the mail alternatives is that make them less than
SMTP is that they are closed. Can't use Signal to call a Skype account.
Everyone has their walled garden, and none of the majors see any reason to
open their proprietary systems up.

But we need to go further, email is also defective as a change of mail
service provider forces me to change my email address unless I own a DNS
domain which is far more than most people on the planet can afford. (No
redirects do not solve this problem as I have to rely on the old service
provider to redirect).

And of course, end to end encryption, digitally authenticate every message
and zero effort security are table stakes.

We need a mail system that allows a user to use their human friendly name
for life. So @alice, not [email-masked]. And that name has to be really
cheap and owned by the user, not rented with an annual fee.

This is not yet operational but I think it could fit the bill:

Mathematical Mesh 3.0 Part VII: Mesh Callsign Service (ietf.org)
<https://www.ietf.org/archive/id/draft-hallambaker-mesh-callsign-00.html>
https://www.ietf.org/archive/id/draft-hallambaker-mesh-callsign-00.html

This architecture is targeted at personal use. DNS works OK for
organizations which is what it was designed for.

Basically it is a blockchain approach without any crypto-currency ideology
involved. The registry binds a name to a public signature key which is the
user's root of trust and the address of their current service provider.

The registry is public so you are not going to want to put an SMTP email
there unless you are a masochist. But the service provider can publish
(under suitable access control) a contact record giving SMTP, Jabber,
OpenPGP, S/MIME etc. coordinates.

Maybe there isn't interest, after all, on day 1 the only use for a
messaging scheme of this type is going to be inside organizations. But that
is where at least 80% of communication is occurring in most enterprises.
Having a separate secure email system for internal use does make sense. And
especially if it then allows communications with the lawyers, accountants,
customers, etc.

---

From: "John Levine" <[email-masked]>
Date: 17 Jul 2021 21:55:51 -0400

>redirects do not solve this problem as I have to rely on the old service

That would be nice, but unless you want mail to be regulated like
telephones, I don't think we want to go there. If someone's mail
address is stable and portable, that means it will be the handle for
lots of accounts, and it will be valuable, so there will arguments
about who really owns an address, and how to reset or recover the
crdentials (including if it's moved to another service without the
user's consent, the mobile phone SIM swap attack) or someone has a
power of attorney or consrvatorship or whatever. I believe your
blockchain will work technically, but these are not problems you can
solve with a blockchain.

I also observe that we have idenntifiers ranging from phone numbers to
drivers' licenses to passports, and few of them are permanent, they change
if you move from one state to another or change providers.  The only one
you can't change in the US is your social security number which is so
overused as to be useless as an identifier.

At this point while I am acutely aware of all of e-mail's problems, it still
is less bad than any replacement on offer.

R's,
John

---

From: Jay Daley <[email-masked]>
Date: Mon, 19 Jul 2021 10:19:40 +1200

When it comes to letting people select the information that they want to get notified about, the concept of a list such as ietf-announce is perhaps a bit out of date.  Nowadays people simply use a form to say, I want this, this and that delivered to this mailbox and that to that mailbox and none of that please.  Behind the scenes this would probably best be implemented with API populated Mailman lists and possibly topics and I’m sure people would want the from address to be stay as [email-masked] <mailto:[email-masked]>, but it might actually be several lists in the background.

Jay

> On 14/07/2021, at 8:14 AM, John Levine <[email-masked]> wrote:
> 
> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
> 

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

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2021 18:22:03 -0400

> When it comes to letting people select the information that they want to get notified about, the concept of a list such as ietf-announce is perhaps a bit out of date.  Nowadays people simply use a…

That's certainly a reasonable way to do it.  To minimize mysterious side 
effects in the mail archive and IMAP server, I'd do it with an API that 
adjusts the topics in one list and leave the lower level stuff alone.  I 
don't think that would be very hard.

R's,
John

>> PS: Some of us don't subscribe to any IETF lists but instead retrieve the messages from the IMAP server, but I think we

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly