Subject: RFC793#ietf.org (was: Re: Proposed ietf.org email address policy)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 11 Jun 2021 14:51:56 -0500

Following up on one point ...

On Fri, Jun 11, 2021 at 12:31 PM Michael Richardson <[email-masked]>
wrote:

>
> 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.
>

I just made sure - I sent to the address that would be my most recent RFC,
and got back "550 5.1.1 <[email-masked]>: Recipient address rejected:
User unknown in virtual alias table".

So, that's a "nope".

The minor question is that I'd expect such addresses to be
[email-masked](*) addresses, but let's ignore that for now.

We might be able to pull this off, going forward, but we're doing AUTH48 on
drafts in the 9040 range now. I'd bet that there are a *lot *of past
authors who aren't reachable at an email address that the RFC Editor knows
about for a variety of reasons

So it would be good to figure out what the objective would be - to find
someone who might still be knowledgeable about the topic of the RFC, or
still caring about the topic of the RFC, or still reading e-mail, or what,
exactly?

One objective might be to find someone who "is responsible for" the RFC -
I was chasing down who was responsible for the work produced by a concluded
WG, literally "yesterday", so that objective seems worthy, but I'm sure
there are others.

Best,

Spencer

(*) Yes, I chose one of Jon Postel's RFCs on purpose ... 😢

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Jun 2021 22:13:52 +0200

Spencer:

I think i asked the tools team similar questions and i think the answers where:

- there are not and never where [email-masked] aliases.
- [email-masked] aliases are also retired after a while.
  I think something like one or two years after expiry or becoming RFC (cannot remember).

Extrapolating from todays discuss also about stable addresses
such as [email-masked], i have to conclude that
you will get any positive feedback from the IETF tools team
to improve communications about RFC than what we have today:

-> To figure out current adresses of authors you have to name match them
   on datatracker and hope they have an account there and are
   updating their email addresss, and if they do not have any active
   role or recent RFC put their current email into the bio section
   (which almost nobody has).

-> To figure out a working group or non-working group mailing list 
   address to discuss an RFC you first need to track back the WG and
   hope its list wasn't closed without being superceeded when it is closed.

Now, of course this is all convoluted and also IMHO not as good as it could
be, but then in fairness to IETF tooling: Show me an SDO that does better.

Cheers
    Toerless

On Fri, Jun 11, 2021 at 02:51:56PM -0500, Spencer Dawkins at IETF wrote:
> (*) Yes, I chose one of Jon Postel's RFCs on purpose ... ????

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2021 17:10:23 -0400

>about for a variety of reasons

No kidding.  Every month I mail a survey to authors and document shepherds of RFCs published
the previous month.  The author addreses are taken from the XML, the shepherds from the Datatracker.
Every month a few of the messages bounce because the addresses are bad, even though they presumably
worked less than a month ago.

I suppose we could try and keep a voluntary address change database, perhaps starting with
the collecion of addresses in the datatracker but I have little confidence it would be updated
reliably enough to be useful.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Jun 2021 23:22:03 +0200

> reliably enough to be useful.

Make it opt-in then:

Those who care about their RFCs can enable the RFC alias.

(Refine by adding quarterly nag mail and disable on delivery failure.
Might need some secretariat support to enable it for older RFCs.)

So I might not get mail through to [email-masked], but would be able to use [email-masked] as a convenient contact address.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Jun 2021 19:12:38 -0400

John Levine <[email-masked]> wrote:
    >> We might be able to pull this off, going forward, but we're doing
    >> AUTH48 on drafts in the 9040 range now. I'd bet that there are a *lot
    >> *of past authors who aren't reachable at an email address that the RFC
    >> Editor knows about for a variety of reasons

    > No kidding.  Every month I mail a survey to authors and document
    > shepherds of RFCs published the previous month.  The author addreses
    > are taken from the XML, the shepherds from the Datatracker.  Every
    > month a few of the messages bounce because the addresses are bad, even
    > though they presumably worked less than a month ago.

Why are you not using draft-foo.all@ for the survey?

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Jun 2021 21:32:15 -0400

--On Friday, June 11, 2021 14:51 -0500 Spencer Dawkins at IETF
<[email-masked]> wrote:

> On Fri, Jun 11, 2021 at 12:31 PM Michael Richardson
> <[email-masked]> wrote:
> 
>> 
>> 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.
>> 
> 
> I just made sure - I sent to the address that would be my most
> recent RFC, and got back "550 5.1.1 <[email-masked]>:
> Recipient address rejected: User unknown in virtual alias
> table".
> 
> So, that's a "nope".
> 
> We might be able to pull this off, going forward, but we're
> doing AUTH48 on drafts in the 9040 range now. I'd bet that
> there are a *lot *of past authors who aren't reachable at an
> email address that the RFC Editor knows about for a variety of
> reasons
> 
> So it would be good to figure out what the objective would be
> - to find someone who might still be knowledgeable about the
> topic of the RFC, or still caring about the topic of the RFC,
> or still reading e-mail, or what, exactly?
> 
> One objective might be to find someone who "is responsible
> for" the RFC - I was chasing down who was responsible for the
> work produced by a concluded WG, literally "yesterday", so
> that objective seems worthy, but I'm sure there are others.
> 
> Best,
> 
> Spencer
> 
> (*) Yes, I chose one of Jon Postel's RFCs on purpose ... p"

For whatever it is worth and IIR, the RFC Editor made an effort
to keep an up-to-date list of contact addresses for RFC authors
25 or 30 years ago.  It was a complete failure, at least in the
sense that it became clear that it would have required a large
amount of ongoing outreach and tracking-down effort on the RFC
Editor's part to even have hope of keeping things up to date.
And that was when we were published far fewer RFCs -- for
example, only around 135 in CY 1995; harder to guess for recent
years because of the number of documents being published out of
chronological order, but I'd guess much larger.  And, again
subjectively the number of authors of whom one would need to
keep track has also grown significantly.   I assume John Levine
has much more exact figures if anyone cared, but I really
suspect this is a dead end without a commitment of significantly
more energy and resources than it is worth.

    john

---

From: "John Levine" <[email-masked]>
Date: 11 Jun 2021 22:34:12 -0400

>more energy and resources than it is worth.

Since we switched to XML in Oct 2019, there have been 687 unique
author addresses. Below is the unsurprising list of all of the domains
with more than two addresses.

We've managed for 50 years without a system to track contact info and at this
point it would be a frustrating full time job to try and do so.  We are already
seeing a lot of authors using gmail for stable addresses and I don't see any
reaspon to try to duplicate that.

R's,
John

('gmail.com', 100)
('cisco.com', 65)
('huawei.com', 24)
('juniper.net', 20)
('google.com', 20)
('ericsson.com', 18)
('nokia.com', 9)
('verisign.com', 8)
('orange.com', 7)
('isc.org', 6)
('att.com', 6)
('apple.com', 5)
('intel.com', 5)
('chinamobile.com', 5)
('ieee.org', 4)
('interdigital.com', 4)
('microsoft.com', 4)
('telekom.de', 4)
('chinatelecom.cn', 4)
('zte.com.cn', 4)
('telefonica.com', 4)
('icann.org', 3)
('ifi.uio.no', 3)
('sinodun.com', 3)
('fb.com', 3)
('bupt.edu.cn', 3)
('cloudflare.com', 3)
('yahoo.com', 3)
('telecom-paris.fr', 3)
('alibaba-inc.com', 3)
('arm.com', 3)
('amazon.com', 3)
('vocal.com', 3)
('nist.gov', 3)
('fh-muenster.de', 3)
('nlnetlabs.nl', 3)
('inria.fr', 3)
('futurewei.com', 3)

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Jun 2021 07:52:05 +0200

On 12. Jun 2021, at 03:32, John C Klensin <[email-masked]> wrote:
> 
> the RFC Editor made an effort
> 25 or 30 years ago.  It was a complete failure,

A nice example for how solid experience can go stale over time.

Background: my department runs an email alias service for alumni.
When students graduate, they can establish mail forwarding to their new address on a self-service portal.
If they don’t update that forwarding address, they are nagged every year (and thus their address is checked), and if they don’t respond, the forwarding expires.
Maybe some 10 or 20 cases of manual intervention every year because forwarding addresses ceased to work or alumni forgot to extend the service in time.

I wouldn’t say that this is totally painless, but it is really low overhead.
Self-service is the ingredient that makes that possible, and opt-in turns it from an administrative nightmare (imagine the administration trying to track mail addresses for *all* alumni) to a really nice feature for those who want to benefit from it.

Of course, some code will be required in datatracker to make this kind of self-service happen, but it would be a limited, justifiable effort, with much of the components already in place.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 10:33:29 -0400

> Background: my department runs an email alias service for alumni.

This is a really really good thing.  It pays for itself entirely in good will
for name recognition, particularly if alumni use the email in papers and
RFCs.   My unversity doesn't have such a thing (AFAIK), but anyway, they have
my mailing address, and send me paper to ask for money.  I don't donate, but
I don't mind them asking.  I *did* really appreciate when the physics
department sent out invitations to everyone who graduated since 1980 or
something when there was a Higgs Boson talk.  {part of ATLAS was built at
Carleton, and the Higgs boson detection experiment was described in a 1972
paper by three professors in the department}

    > If they don’t update that forwarding address, they are nagged every
    > year (and thus their address is checked), and if they don’t respond,
    > the forwarding expires. 
    > Maybe some 10 or 20 cases of manual intervention every year because
    > forwarding addresses ceased to work or alumni forgot to extend the
    > service in time.

Do, the DT basically has 90% of this already, except for the nagging bit and
expiry bit, and we probably should add that anyway.  
We have an entry in our database for each RFC pointing at the authors that
had DT accounts at the time the RFC was published.  The RFC shows up on my
profile page.
For XML drafts (even v2) We could trivally go mechanically through looking
for authors not linked up right.  For authors that are not discovered, we
could nag, and for RFCs with *no* active authors, then we could link to an
appropriate WG, or FOOBAR-AREA.  Okay, some documents are in obsolete "User"
or "SubIP" areas, but maybe the GENDISPATCH area is appropriate for that.

The nag could include a list of RFCs that we know about.

    > Self-service is the ingredient that makes that possible, and opt-in
    > turns it from an administrative nightmare (imagine the administration
    > trying to track mail addresses for *all* alumni) to a really nice
    > feature for those who want to benefit from it.

+1

    > Of course, some code will be required in datatracker to make this kind
    > of self-service happen, but it would be a limited, justifiable effort,
    > with much of the components already in place.

I guess, as John and John asked, we should first establish what the purpose
of having persons responsible for RFCs be contactable.  Some reasons:

  1) it's often the first step of reporting errata, which is getting
     clarification of "did I get this right?"
     
  2) the contact occurs when considering doing FOOBAR-bis, particularly if
     it's in some vendor specific way.  Not every person knows/understands
     the IANA Considerations, and often inexperienced developers don't know
     that there are 845 extensions to DHCPv4, and they don't need to change
     the base document.
  
  3) we could have an auto-responder for RFCs which have been obsoleted,
     telling the person that this is the case.  For those with updates,
     perhaps we would create some kind of cluster.
     For STDxxx this would actually make a lot of sense.

  4) it might be worth having an auto-responder for documents which are not
     via IETF Consensus to say so, and refer the originator to some other
     domain, i.e. [email-masked].

---

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

Michael,

Top-posting to say that if I'd seen this note first, I wouldn't have
replied to Bron, because this is pretty much what I was thinking.

Thanks!

Best,

Spencer

On Sat, Jun 12, 2021 at 9:34 AM Michael Richardson <[email-masked]> wrote:

>     > When students graduate, they can establish mail forwarding to their
> new
>     > address on a self-service portal.