Carsten Bormann <cabo@xxxxxxx> 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. rfc7221@xxxxxxxxxxxxxxxxxxxxx.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
