Subject: Contact handle database for internet-drafts/rfcs?

From: Jeffrey Haas <[email-masked]>
Date: Thu, 9 Jul 2015 17:48:24 -0400

This probably belongs as a more general thread on the ietf mailing list, but
I wanted input from the chairs before I even raised the comment:

Email addresses in RFCs and drafts are sometimes long-used outside the
window of the active document maintenance.  As an example, an errata on a
BFD document just happened, and at least two of the addresses were stale.

By analogy:
Once-upon-a-time, InterNIC gave you a handle associated with your domain
maintenance.  This permitted you to update the handle's email address and
thus maintain some level of portability and indirection on your registration
information.  Some similar mechanism might be useful for our documents.

A point against this is not everyone wants the addresses to be fresh in some
sort of contact database.

Thoughts?

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 9 Jul 2015 17:54:06 -0400

> sort of contact database.

Then make provision and updating of the handle optional?

I'm not sure how much it would help in practice since my observation is that authors are generally either still active in the IETF and thus not THAT hard to find, or have moved on to some unrelated activity. 

That said, I don't see harm in trying it if someone wants to build and host the db. 

--John

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Jul 2015 14:54:36 -0700

Yeah, can i please revive the nic.ddn.mil handle i had in 1986 when
i requested the addresses for my university ? Was trying to find
a copy of that handle text file somewhere but no luck.

Nostalgia aside, an IETF-handle email system would be lovely.
Even better if we could reuse old handles ;-)))

Cheers
   Toerless

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Jul 2015 10:07:08 -0400

> BFD document just happened, and at least two of the addresses were

It seems like we ought to have:
   rfc-XXXX@{rfc-editor.org,ietf.org,spam-me-now.org}

that points to a well-defended (spam-wise) ticket system that can forward
to authors, etc.  This can also return canned information like:
   RFCXXXX was obsoleted by RFCYYYY
   The Errata on RFCXXXX is <HERE>

and we might even remove the author's email addresses entirely from future
documents.  I especially think unicast'ing authors should be discouraged
on WG documents.

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

---

From: Robert Sparks <[email-masked]>
Date: Fri, 10 Jul 2015 09:13:57 -0500

We have at least a place that allows people to keep fresh addresses (in 
the tracker), and mapping from stale addresses to fresher addresses is 
possible, if perhaps not precise.
We also already have the notion of Roles in groups that allow selecting 
a more precise address for someone, and that could be extended to Roles 
on documents at some point in the future.

Hopefully everyone on the chairs list has checked their datatracker 
profile recently
(at https://datatracker.ietf.org/accounts/profile/) to make sure any 
stale addresses are marked as such, and that any addresses that should 
be known for you are listed.

RjS

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 10 Jul 2015 10:25:55 -0400

> -----Original Message-----
> From: WGChairs [mailto:[email-masked]] On Behalf Of Robert
> Sparks
...
> profile recently (at https://datatracker.ietf.org/accounts/profile/) to
> make sure any stale addresses are marked as such, and that any addresses
> that should be known for you are listed.

[ACM] Well, I have now! Thanks Robert.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 10 Jul 2015 14:33:26 -0400

> documents.  I especially think unicast'ing authors should be discouraged

Sometimes the point is to unicast the authors, but I can see there being
preferences to not allow that.

The idea of completely replacing the email with a handle via contact system
is rather appealing, even if it's a bit more than I had originally thought
of.

Spam defense doesn't even have to be particularly strong.  It can just do a
challenge-response before any mail is forwarded.

-- Jeff

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Jul 2015 11:47:13 -0700

+1 rfc-XXXX@... for ticketing, questions, discussions (in that order of
priority).

-- 
---
Toerless Eckert, [email-masked]

---

From: Lee Howard <[email-masked]>
Date: Sat, 11 Jul 2015 15:15:51 -0400

On 7/10/15, 10:07 AM, "WGChairs on behalf of Michael Richardson"
<[email-masked] on behalf of [email-masked]> wrote:

>to authors, etc. 

I¹ve never needed to email the authors of an RFC, so I don¹t know when
that would be useful. If I think it¹s vague, then I probably want the WG
(or a successor WG) to explain, because there might have been multiple
interpretations. And once a document is published, the authors retain no
rights‹do they retain responsibility?
Do errata go to the original authors?
What other cases would this be useful?

> This can also return canned information like:

I would dearly love a tool that draws a tree from an RFC to those RFCs
that update or obsolete it.
Even better would be if it told you which sections were updated.
Bestest would be a single document describing the current complete
definition of a protocol.

>documents.  I especially think unicast'ing authors should be discouraged

Generally, yes, although I sometimes unicast edits and nits. Nobody else
needs to know that they misused a word.

Lee

---

From: Ray Bellis <[email-masked]>
Date: Sat, 11 Jul 2015 20:22:24 +0100

> that update or obsolete it.

I made one of those a few years ago:

<http://download.nominet.org.uk/rfcdeps/>

You have to tell it which RFCs you're interested in, but having done
that it follows the obsoletes / updates chain from the RFC index and
builds graphviz output, e.g.:

<http://download.nominet.org.uk/rfcdeps/svg/dnsproto.svg>

Ray

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Jul 2015 22:46:18 +0300

> On Jul 11, 2015, at 10:15 PM, Lee Howard <[email-masked]> wrote:
> 
> Iąve never needed to email the authors of an RFC, so I donąt know when
> that would be useful. If I think itąs vague, then I probably want the WG

At least for IETF stream RFCs, once they’re published the IETF has taken the responsibility for them.

> Do errata go to the original authors?

Yes, but the responsibility for accepting or rejecting the errata rests with the area director. It’s often the case that the original authors can more quickly answer whether the claim in the report is right or wrong, so they can be helpful to the AD, but they bear no responsibility (and no authority either)

> What other cases would this be useful?

Some people ask the authors before submitting an errata report. Not sure if it’s necessary, but it’s nice.

Yoav

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 11 Jul 2015 15:47:47 -0400

> What other cases would this be useful?

When you are doing a bis for the RFC, and need to figure out the IPR 
going forward.

	Thanks,
	Paul

---

From: Ray Bellis <[email-masked]>
Date: Sat, 11 Jul 2015 21:40:33 +0100

> <http://download.nominet.org.uk/rfcdeps/>

Now hosted at <https://github.com/raybellis/rfcdeps>

NB: the config files need some tweaking to include extra RFCs that may
have been added to those document clusters since I wrote the code.

Ray

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Jul 2015 11:15:01 -0400

> rights‹do they retain responsibility?

In general, one gets emails from students who want help with their homework.
They are often drive-bys --- i.e. even if you reply, you have almost no
chance of actually helping.

    > What other cases would this be useful?

Errata are supposed to go to the WG chairs and ADs for review.
Unicast to authors is usually less reliable in my opinion.

    > that update or obsolete it.

I thought that we had this somewhere.

    > needs to know that they misused a word.

I think that anyone with regular participation in a WG and interaction with
the authors will have the author's addresses in their address book already...
Second, I am not proposing to remove author's email addresses from IDs!
Just RFCs.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 13 Jul 2015 14:59:29 +0000

> On Jul 11, 2015, at 12:15 PM, Lee Howard <[email-masked]> wrote:
> 
> rights<do they retain responsibility?

One might ask, then, why author email addresses go into RFCs. The usual reason for the latter is "I'd like to discuss something with the author". I probably get one of those a month.

What bothers me with that is that folks' email addresses change, but RFCs don't. The information becomes stale as a result. It might be nice to have something (perhaps at the RFC editor's office) that contains the authors' *current* email addresses.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 13 Jul 2015 11:52:05 -0400

> What bothers me with that is that folks' email addresses change, but RFCs don't. The information becomes stale as a result. It might be nice to have something (perhaps at the RFC editor's office) t…

This thread seems to have moved to "don't put e-mail addresses in the RFC,
put a mechanism that leads to a contact form".

I'm supportive of that idea.

-- Jeff

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Jul 2015 16:17:32 +0200

> I'm supportive of that idea.

-1. I like having email addresses in there. IEEE runs something like
<your_name>@computer.org, which will then forward to
[email-masked]. I'm still not really sure of the issue we are
trying to solve, but perhaps IETF could run something similar....

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Jul 2015 13:38:25 -0400

> trying to solve, but perhaps IETF could run something similar....

To reiterate the discussion point, email addresses in RFCs go stale.  We
have internal IETF infrastructure that tries to send mail to those
addresses.  Presumably we put them in the RFC so things that aren't IETF
software can contact the relevant humans.

There's a good case that we want the IETF software to have current mappings.

The case of letting random humans contact RFC authors via email seems
somewhat disputed. :-)

Is having an email address in the RFC valuable?  Is having an alternate
method of contact managed by IETF and mapping to a current address better?
Examples include handles like we used to have on domains or your own
observation of an IETF email redirector.

-- Jeff

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jul 2015 13:47:23 -0400

ISTM that both of the following happen with regularity:

- an author changes addresses yet still wants to be reachable regarding 
his RFCs

- an author retains his address yet no longer wants to be reachable 
regarding his RFCs

And, that may vary from one RFC to another for the same author. And 
there may be differences depending on who is trying to reach him, and 
why. (E.g., Editor of subsequent bis vs. random student working on 
homework.)

Simply supporting [email-masked] would provide a foundation for 
supporting author preferences.

	Thanks,
	Paul

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 14 Jul 2015 18:01:00 +0000

> On Jul 14, 2015, at 7:17 AM, Warren Kumari <[email-masked]> wrote:
> 
> IEEE runs something like

I could easily imagine something like [email-masked] or @authors.ietf.org.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Jul 2015 14:04:56 -0400

On Tue, Jul 14, 2015 at 01:47:23PM -0400, Paul Kyzivat wrote:
> - an author changes addresses yet still wants to be reachable
> regarding his RFCs
> 
> there may be differences depending on who is trying to reach him,
> and why. (E.g., Editor of subsequent bis vs. random student working
> on homework.)
> 

I agree.  We already have [email-masked].  Do we require
anything more than [email-masked] as above?

The distinguishing point, I think, is if I was JMH32 in the IETF database, I
need only worry about one thing to update.  The RFC alias mapping to that
handle is merely an aggregation.

-- Jeff

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 14 Jul 2015 19:18:03 +0000

> On Jul 14, 2015, at 10:38 AM, Jeffrey Haas <[email-masked]> wrote:
> 

My company gets curious, because our customers and senior management ask, what projects we have been involved with. I use the email addresses as a way of deriving that information. If we remove the email addresses, I will find it useful to have that information by some other way.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 Jul 2015 22:21:03 +0200

> be known for you are listed.

Sure.  I just have no idea  what the choices on that page actually do,
so I'm not inclined to change what seems to mostly work for me right now.

E.g., what does it mean to "deactivate" an email address?
Why is the list of roles a dropdown of email addresses?
What is the "preferred form of my name" actually being used for?
Preferred by whom?

(This is one of the forms that are hard to get right if you happen to
know how datatracker works.)

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Jul 2015 17:12:16 -0500

> E.g., what does it mean to "deactivate" an email address?
That the tracker won't try to send mail to it, include it in places 
where it offers lists of addresses to choose from, or when it generates 
aliases like those at http://datatracker.ietf.org/doc/email-aliases/

> Why is the list of roles a dropdown of email addresses?
People have asked to use different email addresses for different roles.
> What is the "preferred form of my name" actually being used for?
This is harder than I think it should be, as it happened organically 
over many years, but roughly:

Name is a UTF-8 field that holds your name as you want it presented. It 
is what the code tries to use unless circumstances say otherwise.

One such circumstance is when we are forced to use an ascii only 
rendition. Then what's entered in the ASCII field is used. (I'm not 
going to try to list those places off the top of my head - I can build a 
list later though, and like lots of organically grown things, this could 
use some maintenance).

The code uses heuristics to generate a first-initial, last-name form 
from ASCII (historically for use in things like generating bibxml).

The 'Ascii short' field is a bandage that allows people to tell the 
tracker what to use when the heuristics get it wrong.

> Preferred by whom?
You.
> know how datatracker works.)
Ack.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 15 Jul 2015 03:14:04 +0000

> On Jul 11, 2015, at 9:46 PM, Yoav Nir <[email-masked]> wrote:
> 

And sometimes folks contact the authors of an RFC for advice on its deployment. I have a meeting of that category on Friday. The operator in question contacted me, and we agreed to meet in person to discuss his use case.