Subject: Proposed ietf.org email address policy

From: IETF Chair <[email-masked]>
Date: Thu, 10 Jun 2021 20:52:13 +0300

We are proposing a policy regarding the allocation of individual
administrative email addresses in the ietf.org domain. The proposal
was motivated by a few community members that raised the concern that
continued allocation of individual email addresses under ietf.org
could at some point create collisions for IETF mailing lists.

Historically, the only email addresses created under the ietf.org
domain were for IETF-associated mailing lists, e.g., for working
groups, the IESG, directorates, etc., for aliases for certain roles,
e.g., [email-masked], or for administrative purposes, e.g.,
[email-masked]. This was not the result of following any explicit
allocation policy, it just happened that way.

This expanded slightly a number of years ago, on an ad hoc basis, and
now a few individuals - all of them IETF LLC employees - have work
email addresses under ietf.org.

Therefore, the IESG and LLC Board are considering formalizing a policy
concerning ietf.org email addresses:

* new email addresses for general and administrative roles under
  ietf.org must be chosen to avoid conflicts with potential IETF
  mailing list names

* the IESG must be consulted before any new email addresses under
  ietf.org are created and will have the sole responsibility for
  approving and managing addresses under ietf.org

* new individual email addresses for LLC personnel will be allocated
  under a new staff.ietf.org subdomain, with the LLC being solely
  responsible for the approval and management of those addresses

* existing individual email addresses under ietf.org at the time the
  policy goes into effect will continue to receive email, which will
  be forwarded to new staff.ietf.org subdomain addresses; and
  outbound mail should be preferably be sent from staff.ietf.org
  addresses or role-based ietf.org addresses

We invite the community to send feedback on this proposed policy to
[email-masked] by 24 June 2021.

Lars Eggert
IETF Chair

Jason Livingood
Chair, IETF LLC Board

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Jun 2021 18:01:02 +0000

I like this proposal very much.

---

From: Fred Baker <[email-masked]>
Date: Thu, 10 Jun 2021 11:16:36 -0700

Thanks for this. Your proposed rule makes sense. I might have one suggestion.

Where you have allocated an email address in IETF.org for an individual, duplicate that with an address in staff.IETF.org.  That will allow you, at some point in the future, to remove the first set of addresses and continue communication with the second. I might suggest that those individuals start using the @staff email addresses so reduce any possible impact when that is done.

JUst a thought.

Sent from my iPad

> On Jun 10, 2021, at 10:53 AM, IETF Chair <[email-masked]> wrote:
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Jun 2021 14:53:55 -0400

Fred,

I think that is already in the proposal -- see the last bullet
point ("* existing individual email addresses under ietf.org...")

Lars and Jason,

Seems completely sensible to me and is fairly similar to what I
would have proposed if asked (probably just a happy
coincidence).  One tiny suggestion and a question:

* At least for the benefit of those of us with fat fingers, have
you considered a subdomain shorter than "staff".  "llc.ietf.org"
or even "co.ietf.org" or "ad.ietf.org" would seem to have small
advantages if done at the beginning?

* Several people who are not employees of the LLC, particularly
Secretariat Staff working for AMS, already have ietf.org role
accounts.  As I understand the proposal, that does not change.
They are now using AMSL.COM addresses when those role account
are inappropriate (or they don't have role accounts).  I assume
that does not change.  Correct?

Again, seems like a very good proposal and plan.

thanks,
   john

--On Thursday, June 10, 2021 11:16 -0700 Fred Baker
<[email-masked]> wrote:

> Where you have allocated an email address in IETF.org for an
> individual, duplicate that with an address in staff.IETF.org.
> That will allow you, at some point in the future, to remove
> the first set of addresses and continue communication with the
> second. I might suggest that those individuals start using the
> @staff email addresses so reduce any possible impact when that
> is done.
> 
> JUst a thought.

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Jun 2021 21:14:29 -0400

This looks good to me.

Keith

---

From: Lloyd W <[email-masked]>
Date: Fri, 11 Jun 2021 16:35:47 +1000

Has the IESG considered renting out @member.ietf.org or @supporter.ietf.org addresses as a potential revenue stream? Throw in a free github account to sweeten the deal and so that access to discussion is not unnecessarily limited.

Lloyd Wood
[email-masked]

At last, I'll be able to hide the shame of using a yahoo address.

> On 11 Jun 2021, at 03:53, IETF Chair <[email-masked]> wrote:
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Jun 2021 10:40:55 -0400

--On Friday, June 11, 2021 16:35 +1000 Lloyd W
<lloyd.wood=[email-masked]> wrote:

> Has the IESG considered renting out @member.ietf.org or
> @supporter.ietf.org addresses as a potential revenue stream?
> Throw in a free github account to sweeten the deal and so that
> access to discussion is not unnecessarily limited.

Lloyd,

Prior experience with people being allowed to set up
IETF-provided mailing lists for discussions that seemed rather
far out on the edges of IETF work, deliberate misrepresentations
of Informational RFCs or even I-Ds as IETF standards, etc.,
suggests that it would be a small jump from
[email-masked] (and what is a "Member" or the IETF
anyway?), [email-masked], or even
[email-masked] from even worse misrepresentations
about positions and authority.

So I think this idea goes into the "proceed carefully and be
careful what you wish for" category even if not in the "just
plain bad idea" one.

best,
   john

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Jun 2021 13:30:03 -0400

>> @supporter.ietf.org addresses as a potential revenue stream?  Throw in
    >> a free github account to sweeten the deal and so that access to
    >> discussion is not unnecessarily limited.

    > Prior experience with people being allowed to set up IETF-provided
    > mailing lists for discussions that seemed rather far out on the edges
    > of IETF work, deliberate misrepresentations of Informational RFCs or
    > even I-Ds as IETF standards, etc., suggests that it would be a small
    > jump from [email-masked] (and what is a "Member" or the IETF
    > [email-masked] from even worse misrepresentations about
    > positions and authority.

I see your point, so I suggest maybe it be restricted to people with
published RFCs.
Being able to put a stable contact into an RFC seems like a good thing to me.

I know we have [email-masked] aliases, and those can get updated via the
DT, I'm unclear if I can email [email-masked] to reach the authors, and
that's not what's listed in the RFC.

As for member, supporter, etc. I'd suggest "contributor.ietf.org".

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2021 13:45:21 -0400

It appears that Lloyd W  <[email-masked]> said:
>Has the IESG considered renting out @member.ietf.org or @supporter.ietf.org addresses as a potential revenue stream? Throw
>in a free github account to sweeten the deal and so that access to discussion is not unnecessarily limited.

Having some familiarity with the mail business, there is no chance
that something like this could break even, much less make any money,
even if it was supposed to just forward mail to other addresses. I
forward mail for some of my users and it is a huge pain between the
legit mail that gets bounced by the target systems, the stuff my spam
filters catch that the recipients actually want, and the spam that
leaks through, they hit the junk button, and I get the complaint.

We're a standards organization.  Let's work on standards development.

R's,
John

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Jun 2021 20:26:04 +0200

I guess whoever is in support of such email adresses could
write an RFC, and i think it should include proposals how
to create such a service.

I am not on top of the email business these days, but i would
be surprised if there where no commercial email providers where
some operationalizing option could be made to work if there was interest:

Something like:

  a) members.ietf.org Is handed over to that company (SOA, MX, whatever is needed)
  b) provider comes up with charging model, IETF is not involved in anything.
  c) Upon opening account, some authentication with datracker is done,
     e.g.: open a <whatever>@members.ietf.org email account you need
     to prove to be owner of a datatracker account.

Just one option. Maybe more interesting to IETF:

  a) During registration for IETF, one is offered to pay extra
     for an N-month (renewal) of email-forwarding for some $XXX.
  b) The email forard is set up via cloudflare email forwarding app,
     given how IETF is already using cloudflare.
  c) some good amount of $XXX is kept by IETF

Cheers
    toerless

---

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 12 Jun 2021 23:50:40 +1000

>   c) some good amount of $XXX is kept by IETF

I am in that business, and I expect that the small subset of IETF participants that would be willing to pay for such a service wouldn't justify a reasonable price.  I'm not sure what "some $XXX" you're imagining here, or what uptake you would expect, but the headache of setting this up and maintaining it would be unlikely to leave "some good amount" for the IETF.

Anyways, the IETF already has mail forwarding infrastructure, per the alias expanders for all the drafts.  The difference is between "a static contact address" (which I see some value in having for every RFC that can be updated or directed to the most relevant working group if the RFC is abandoned by its original authors), and an address which people might start signing up as the target for significant volumes of non-person-to-person traffic.

Bron.

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 12 Jun 2021 09:48:07 -0500

Hi, Bron,

On Sat, Jun 12, 2021 at 8:52 AM Bron Gondwana <[email-masked]>
wrote:

>
> Anyways, the IETF already has mail forwarding infrastructure, per the
> alias expanders for all the drafts.  The difference is between "a static
> contact address" (which I see some value in having for every RFC that can
> be updated or directed to the most relevant working group if the RFC is
> abandoned by its original authors), and an address which people might start
> signing up as the target for significant volumes of non-person-to-person
> traffic.
>

Right. So I was thinking of a static contact address in my previous note.

I think we're back to the question of what we hope to accomplish, which
might be to have some contact for each RFC (or each standards-track RFC, or
something. Mumbles) that could direct traffic on where to go next.

I think the IESG (as a whole or as individual ADs, if you're good at
guessing which one) is the last resort now, for people who want to follow
up about an RFC and who can figure that out.

This would be somewhat similar to having the IESG as contact for (some)
IANA registries, rather than a person or a WG that might conclude.

Does that make sense? Not as "the goal", but as one possible goal that
might be worth considering.

Best,

Spencer

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 11:59:17 -0400

Spencer Dawkins at IETF <[email-masked]> wrote:
    > might be to have some contact for each RFC (or each standards-track
    > RFC, or something. Mumbles) that could direct traffic on where to go
    > next.

    > guessing which one) is the last resort now, for people who want to
    > follow up about an RFC and who can figure that out.

I don't think that random non-IETF RFC reader would know to contact the IESG!

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Jun 2021 12:14:50 -0400

--On Saturday, June 12, 2021 09:48 -0500 Spencer Dawkins at IETF
<[email-masked]> wrote:

>...

> I think we're back to the question of what we hope to
> accomplish, which might be to have some contact for each RFC
> (or each standards-track RFC, or something. Mumbles) that
> could direct traffic on where to go next.
> 
> I think the IESG (as a whole or as individual ADs, if you're
> good at guessing which one) is the last resort now, for people
> who want to follow up about an RFC and who can figure that out.
> 
> This would be somewhat similar to having the IESG as contact
> for (some) IANA registries, rather than a person or a WG that
> might conclude.
> 
> Does that make sense? Not as "the goal", but as one possible
> goal that might be worth considering.

Spencer,

Suppose we are talking only about standards-track RFCs (other
categories and other streams might pose other issues)  Now, I
regularly get queries about the interpretation of ancient
standards-track RFCs with my name on them, even ones that the
IETF considers absolute and ones that show addresses that have
not worked for a couple of decades.  As few weeks ago, I even
got an inquiry about RFC 1425.  Now, for any inquiry about 1425
that is not strictly about history, the answer is "see 5321" and
maybe a comment about EMAILCORE.  But I got the inquiry and I
get inquiries about, e.g., 5321 and 6530 a lot more often.
However, the problem is the same as that for non-editorial
errata: these are standards-track, IETF consensus documents, and
no one should be giving an authoritative interpretation that
does not involve IETF consensus.  Maybe the IESG is an adequate
interpreter of what that consensus would be if, e.g., a Last
Call were put out, maybe not.

But that suggests that, at least for standards-track documents,
having people ask questions directly of the authors and expect
authoritative responses is something we should be discouraging,
not encouraging.   Perhaps, especially if the IESG needs more
work to do, we should be modifying the RFC boilerplate to
indicate that questions about the document should be addressed
to the IESG or some AD role account (one that we be sure to
redirect to the IESG if we eliminate areas).   But making
authors, especially authors who have not been involved with the
subject matter or in the IETF for years, easier to find is
probably just the wrong idea.

    john

      john

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 13:20:57 -0400

John C Klensin <[email-masked]> wrote:
    > not encouraging.

I think such things should go into a bugtracker/ticket system, with the
authors and WG notified.   I'd move all errata into such a system.

I think our current rfc-editor errata interface is too bespoke and simple.
The system I'd want is an instance of stackoverflow/serverfault/askubuntu/etc.
It just needs IESG members to be blessed with a really high reputation during
their tenure.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jun 2021 08:49:13 +1200

On 13-Jun-21 02:48, Spencer Dawkins at IETF wrote:
...
> I think the IESG (as a whole or as individual ADs, if you're good at guessing which one) is the last resort now, for people who want to follow up about an RFC and who can figure that out. 

It's rather odd, when you think about it, that all RFC's don't contain boilerplate like:

This is a Request for Comments. If you have any comments, please send them to [email-masked].

   Brian

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 13 Jun 2021 13:14:04 +0100

Hiya,

> authoritative responses is something we should be discouraging,

Disagree. One of the good things about the RFC series
and IETF specs is that they are written by sets of
contactable humans.

I don't think there's a real problem with authors giving
secret advice that goes against IETF consensus so let's
not change/break anything for that reason.

S.

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Jun 2021 13:47:15 -0400

--On Sunday, 13 June, 2021 13:14 +0100 Stephen Farrell
<[email-masked]> wrote:

>> But that suggests that, at least for standards-track
>> documents, having people ask questions directly of the
>> authors and expect authoritative responses is something we
>> should be discouraging, not encouraging.
> 

often contactable.

> not change/break anything for that reason.

First, I don't see enough of a problem to justify a change in
what we have been doing.  I am only concerned that making it
easier to find the authors of older RFCs might not be as good an
idea as it might appear to be on first glance.  I'm worried
about two cases.  And let me apologize in advance for saying
what amounts to "this is part of a larger problem and a quick
fix to part of it might make things worse".  But it is and it
could.

 (1)  Assume someone wrote or co-wrote an RFC many years ago,
but has subsequently dropped out of the IETF.  In the
intervening period and without that author being involved or
knowing about it, the IETF consensus on what is specified and/or
how it should be interpreted or applied has changed.  That
author, even with all good intentions, may not be the most
reliable source of information.  

As a personal example, I think I mentioned that I recently
received a query about what they believed to be an ambiguity in
RFC 1425.   Now I have stayed around, know what has happened
since, and responded to the question by pointing the person who
asked to 5321 and suggesting the EMAILCORE list if they believed
there was still an ambiguity.   But suppose that, sometime in
late 1993, I had decided I had had enough of email
specifications and the IETF generally, dropped out, and stopped
paying attention to any of this.  Would we really, really, want
questions about variations on SMTP addressed to me in 2021?

 (2) I don't know about your experience but, at the direction of
WGs for whom I've been acting as author/editor, I have sometimes
written things into documents that became RFCs with which I
profoundly disagree.  In many cases, subsequent experience has
proven the WG to have been correct.  In others, similar
experience shows that I was right in the first place.  Now, with
the understanding that, in such situations "what do you think I
should do in case ABC?" and "what does the standard intend be
done in case ABC?" are different questions and that even the
person asking may not know the difference, how should the
author, especially an author who believe that that should not
write response more than 240 characters long, respond?   "What
is the history of that particular decision" is yet another
question, one on which I'd assume the author would be
authoritative.

In both cases, if we were better at making notes when experience
and/or consensus changes and in making it obvious which
specifications, comments, updates, notes, etc., go together, we
would have fewer problems.  AFAICT, we know of two ways to
provide that sort of information:

(a) Figure out better ways to index, collect, and/or annotate
the content of documents in ways that make relationships and
current thinking clear.  The late (and lamented by some) efforts
of the NEWTRK WG proposed one or two ways to do this and,
although I don't remember its being explicitly proposed, those
documents could contain best current contact information for
documents or sets of them.

(b) More or less abandon the notion of static RFCs with fixed
number assignments as representations of our standards.  That
could be done  by adopting a model similar to ISO's in which (to
use historical examples I would not recommend trying to change)
the successor to specification 760:1980 would be 760:1981 (not
791) and the first update that does not completely replace the
base specification would be 760:1980-Amendment1 (or
"...-Amendment1(1992)", not 1349.  Or we could go all the way to
expressing standards as living documents, updated in place any
time there was consensus about a change or correction and with
no notion of static documents other than tracking history.  

Does that explain the concern better?

best,
   john

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Jun 2021 20:58:20 +0200

On 2021-06-13, at 19:47, John C Klensin <[email-masked]> wrote:
> 
> Would we really, really, want

But would you have opted in?

The only situation where easier access to the authors might be construed harmful is where the WG or IESG had to hamstring the author in order to obtain an acceptable outcome.  Private conversation with the author might not benefit from that influence.

But that is true for any kind of contact with the author, and a lot of people do find my email address in RFCs I have co-authored and manage to send email to that.

So with all the horror scenarios of people outside the IETF actually talking to authors, I still think this is a net win.

Grüße, Carsten

---

From: Aqua Q Glass <[email-masked]>
Date: Sun, 13 Jun 2021 13:10:10 -0700

a metadata ammendment towards the [RFC,documents] which supersede prior
art, as denoted and approved with new documents, will provide hypertext and
dedupe questions.. and additionally a place for IETF to maintain FAQs
around relatable RFCs, online vs. adhoc email, and with authenticity.

#aQ

---

From: [email-masked]
Date: Sun, 13 Jun 2021 14:21:04 -0700 (PDT)

I'm with John in believing that there isn't enough of a problem to justify any
sort of change. In fact I'll go further and say that I think we have achieved,
perhaps unintentionally, a pretty effective balance, where authors can be
contacted, albeit with some effort, with effort increasing as specifications
age.

Like it or not, there are cranks out there, and sadly they can appear on both
sides of the equation. (This not to say this has happened in the case of RFC
authors - AFAIK it hasn't yet - but it most certainly has been a problem with
authors of important documents in other disciplines.)

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Jun 2021 19:37:44 -0400

--On Sunday, 13 June, 2021 13:10 -0700 Aqua Q Glass
<[email-masked]> wrote:

> a metadata ammendment towards the [RFC,documents] which
> supersede prior art, as denoted and approved with new
> documents, will provide hypertext and dedupe questions.. and
> additionally a place for IETF to maintain FAQs around
> relatable RFCs, online vs. adhoc email, and with authenticity.

It turns out to be not quite that easy, especially if one tries
to avoid making other significant changes.  This is, however,
exactly the territory that NEWTRK [1] starting about 2004 and
running through 2006 or so, with periodic attempts to restart or
build on that work.

While I believe that, after nearly 15 years, it is time to look
at these questions again, I don't believe anyone who was heavily
involved in that original effort would recommend initiating a
follow-up effort (or a completely new one with similar goals)
unless it was clear that the IESG was prepared to accept and
process whatever conclusions and consensus that WG managed to
reach.

Happy reading.
   john

[1] https://datatracker.ietf.org/wg/newtrk/about/

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Jun 2021 19:55:38 -0400

> But would you have opted in?

That is where I might not be typical enough to make a good
example.  I seem to suffer from an odd, perhaps pathological,
sense of responsibility where the Internet is concerned.and sp
the answer to your question is "probably", especially if things
were set up so that the alternates to my signing up were people
tracking me down anyway (see Ned's note) or inquiries going to
somewhere other than a set or ADs who were enthused about the
mob.

> The only situation where easier access to the authors might be
> construed harmful is where the WG or IESG had to hamstring the
> author in order to obtain an acceptable outcome.  Private
> conversation with the author might not benefit from that
> influence.

This may be just a quibble, but there is a rather large
difference between "author puts something into a document on the
nistrutions of a WG with which they disagree" and "need to
hamstring or otherwise torture".  Depending on the circumstances
and personality of the author, "might not benefit" might set it
well before the authors needed to be subject to physical harm.

> But that is true for any kind of contact with the author, and
> a lot of people do find my email address in RFCs I have
> co-authored and manage to send email to that.
> 
> So with all the horror scenarios of people outside the IETF
> actually talking to authors, I still think this is a net win.

I agree with Ned and his explanation of why the balance we have
today is just about right.

best,
   john

---

From: Adam Roach <[email-masked]>
Date: Sun, 13 Jun 2021 20:40:24 -0500

I think this proposal takes things in the right direction. Thanks to 
everyone who worked to craft the policy.

/a

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 14 Jun 2021 06:49:39 +0200

> today is just about right.

This is all wrong.

Normally, it is the Germans who see the potential problems of some innovation and run around preventing things from happening because something *could* go wrong.
We even have a common word for that stereotype that is so widely spread in Germany, the “Bedenkenträger” (= “bearer of concerns”).

Now, if I find myself on the side of arguing for change where others are clinging to the status quo, I find this deeply concerning.

Grüße, Carsten

(If you didn’t notice, this is all tongue in cheek.
But I’m still amazed by what dangerous animals these ex-RFC-authors must be that we can’t expose them any further.)

---

From: Larry Masinter <[email-masked]>
Date: Sun, 13 Jun 2021 22:13:57 -0700

> Normally, it is the Germans who see the potential problems of some
> innovation and run around preventing things from happening because
> something *could* go wrong.
> We even have a common word for that stereotype that is so widely spread in
> Germany, the “Bedenkenträger” (= “bearer of concerns”).

The service of bringing concerns is mainly what IETF offers. 
Each call for consensus, each draft, each Request For Comments is
asking for more concerns.

Rough consensus is that "there are no more significant, unaddressed concerns".
Being "Bedenkenträger" Is what we're here for.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 14 Jun 2021 01:39:29 -0400

Your concern is that as an RFC author, people might not be able to bring
their concerns to you.

On Mon, Jun 14, 2021 at 12:50 AM Carsten Bormann <[email-masked]> wrote:

> Now, if I find myself on the side of arguing for change where others are
> clinging to the status quo, I find this deeply concerning.
>
> Grüße, Carsten
>
>
> But I’m still amazed by what dangerous animals these ex-RFC-authors must
> be that we can’t expose them any further.)
>
>

---

From: Scott Bradner <[email-masked]>
Date: Mon, 14 Jun 2021 06:40:43 -0400

+1

> On Jun 13, 2021, at 7:37 PM, John C Klensin <[email-masked]> wrote:
> 
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 14 Jun 2021 07:46:07 -0500

Normally I don't +1 to email threads, but +1 here, because I think
Scott's +1 on John's observation is overwhelmingly correct.

Spencer