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

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> wrote:

>
> Carsten Bormann <[e-mail]> wrote:
>     > 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}
>
>     > 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.
>
> 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.
>
>     > 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.
>
> +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. [e-mail].
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>