Re: [Tools-discuss] datatracker, I-Ds, and email addresses

John C Klensin <john-ietf@jck.com> Wed, 31 May 2023 23:18 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BE2C15155F for <tools-discuss@ietfa.amsl.com>; Wed, 31 May 2023 16:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKtN9nvXqC5d for <tools-discuss@ietfa.amsl.com>; Wed, 31 May 2023 16:18:52 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD85C15107D for <tools-discuss@ietf.org>; Wed, 31 May 2023 16:18:52 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1q4V5f-00087w-4H; Wed, 31 May 2023 19:18:51 -0400
Date: Wed, 31 May 2023 19:18:36 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, tools-discuss@ietf.org
Message-ID: <0FBF3D1488886DC62EC9FE43@PSB>
In-Reply-To: <2613e5c9-0437-8d8a-6c74-11f3c625b1e9@gmail.com>
References: <CF14A35ABED1122EC614AF81@PSB> <0298e627-b433-4ecb-0c29-cd395079de6e@gmail.com> <D94D78B548161F0ECFD69111@PSB> <17FA35AD-F786-48B0-8EC5-46A8EFAD90E0@ietf.org> <a6ba4484-e3b6-613c-69b0-e570cb339b4b@gmail.com> <8742D52A-A3C7-42FB-98E8-B83BC930DB6D@ietf.org> <759ff75a-9334-53ce-8348-e22c14a84509@nostrum.com> <2613e5c9-0437-8d8a-6c74-11f3c625b1e9@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/morVPHb9tAmO9K2V9fpB8d5whcc>
Subject: Re: [Tools-discuss] datatracker, I-Ds, and email addresses
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2023 23:18:56 -0000


--On Thursday, June 1, 2023 08:11 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> On 01-Jun-23 01:37, Robert Sparks wrote:
>> The Primary address is the user's choice. An address is never
>> made Primary except by the user.
> 
> In the case that started this thread, it's possible that the
> DT record was old enough that it was set automagically many
> years ago. There was certainly a time when it wasn't under the
> user's direct control.

That is "set at all, much less set as Primary" -- some of the
relevant documents and addresses predate the datatracker by a
decade or more.
 
>> When the datatracker sends mail, it uses the Primary if it
>> has been set, and the most recent "Active" email address if
>> it hasn't.
>> 
>> (See
>> https://github.com/ietf-tools/datatracker/blob/f8e18991084704
>> 494863506fcd2e756efc2abc2a/ietf/person/models.py#L141-L147 if
>> you're curious).
>> 
>> As Jay notes, there are many ways the datatracker can
>> associate an email with a person.
> 
> Indeed. My comment was that the DT for whatever reason tagged
> my (primary) address with the I-D I most recently submitted,
> although that address has been in the tracker for many years.

And I guess I'm trying to make a different point, which is that,
if the Datatracker is sending mail about a particular document
it should use the address specified in that document, unless the
author makes a document-specific request to use something else
(and I believe the author should do that only by revising the
I-D, but YMMD).

There is another sort of example in which that distinction, and
the "trust what the I-D says" strategy is important.  Suppose
someone is an independent consultant who does significant IETF
work under their consulting address, JoeSmith@example.com.  That
is the address in the tracker and the one Smith uses when they
post draft-smith-whatever-00 (for multiple variations on
"whatever").   But suppose they also take on work for FooCorp to
generate a document about how FooCorp does Baz.  The document
gets posted as draft-smith-foocorp-baz-00 and contains Smith's
FooCorp address, JoeSmith@foocorp.example.  The latter is
something FooCorp might even insist on contractually in order
that they be able to maintain records about all communications
about that draft.  If the datatracker insists on sending mail
about the latter document to the JohnSmith@example.com address,
that could have a series of bad consequences.  FooCorp could
easily decide that participating in the IETF or sponsoring
individuals to do so is not in their interest.  They, and even
Joe, could conclude that the IETF is seriously non-inclusive
because the IETF procedures do not treat them, and the way they
operate and obtain advice, legitimate or worthy of being allowed
to participate.

At least IMO, we should not go there.  And, if we do go there,
it should be an IETF consensus decision about the balance
between inclusively and other objective rather than a side
effect of implementation decisions about how the datatracker
works.

best,
   john


> 
>     Brian
> 
>> 
>> RjS
>> 
>> 
>> On 5/31/23 4:48 AM, Jay Daley wrote:
>>> 
>>> 
>>>> On 30 May 2023, at 22:42, Brian E Carpenter
>>>> <brian.e.carpenter@gmail.com> wrote:
>>>> 
>>>> On 30-May-23 21:35, Jay Daley wrote:
>>>>> John
>>>>> Are you suggesting that when an I-D is submitted, the
>>>>> email addresses of the authors are automagically added to
>>>>> their Datatracker profiles, even if they themselves
>>>>> omitted to do that?
>>>> 
>>>> Looking at my own profile, my primary address is listed as
>>>> 
>>>> "brian.e.carpenter@gmail.com author:
>>>> draft-ietf-6man-rfc6874bis"
>>>> 
>>>> which strongly suggests that the DT actively tracks
>>>> submissions, since that is the draft that's been
>>>> (re)submitted most recently.
>>> 
>>> So you haven't provided that any other way, say when
>>> registering for a meeting?
>>> 
>>> Jay
>>> 
>>>> 
>>>> But the *primary* address is presumably user-choice?
>>>> 
>>>>   Brian
>>>> 
>>>>> Jay
>>>>>> On 28 May 2023, at 01:36, John C Klensin
>>>>>> <john-ietf@jck.com> wrote:
>>>>>> 
>>>>>> Brian,
>>>>>> 
>>>>>> Yes, typo.  Sorry.
>>>>>> 
>>>>>> And, yes, I can imagine such a heuristic.  At the same
>>>>>> time, if that most recent RFCs is decades old and the
>>>>>> (new) I-D is fully posted, it seems to be that a
>>>>>> competent heuristic would either go with the information
>>>>>> in the I-D or point the inconsistency out and ask for
>>>>>> human assistance.   (FWIW, I am not able to figure out
>>>>>> what it would mean to identify an I-D as less than fully
>>>>>> posted when the announcement had bee sent to
>>>>>> IETF-announce, the datatracker page was up, and the
>>>>>> document was online in the places that both specified,
>>>>>> all of which are the case here.)
>>>>>> 
>>>>>> best,
>>>>>>   john
>>>>>> 
>>>>>> 
>>>>>> --On Sunday, May 28, 2023 11:53 +1200 Brian E Carpenter
>>>>>> <brian.e.carpenter@gmail.com> wrote:
>>>>>> 
>>>>>>> To avoid confusion, I think you mean RFC 2693.
>>>>>>> 
>>>>>>> I'd guess that we are dealing with a heuristic for the
>>>>>>> case where
>>>>>>> the DT profile is incomplete. "Use the most recent RFC"
>>>>>>> might appear safer than "use the most recent I-D" in
>>>>>>> some lights. Or maybe "use the most recent I-D" won't
>>>>>>> work before the I-D has been fully posted.
>>>>>>> 
>>>>>>> Regards
>>>>>>>    Brian
>>>>>>> 
>>>>>>> On 28-May-23 11:24, John C Klensin wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Until very recently, I assumed that the email addresses
>>>>>>>> shown in the Datatracker, particularly those shown on
>>>>>>>> the home pages for various I-Ds, would be the most
>>>>>>>> up-to-date ones we had except, possibly, for old I-Ds
>>>>>>>> where they might reflect the addresses shown as Author
>>>>>>>> Address information in those I-Ds.
>>>>>>>> 
>>>>>>>> That does not appear to be the case.   If one examines
>>>>>>>> https://datatracker.ietf.org/doc/draft-rivest-sexp/
>>>>>>>> an address is shown for the first author, Ronald L.
>>>>>>>> Rivest, of rivest@theory.lcs.mit.edu.  His datatracker
>>>>>>>> page does not show any email addresses at all.  RFC
>>>>>>>> 1186 (October 1990) shows that address under Author's
>>>>>>>> Addresses as does RFC 2593 (September 1999).  But that
>>>>>>>> address has been dead, or at least not-preferred, since
>>>>>>>> at least July 2003 when LCS was merged into CSAIL and
>>>>>>>> MIT, IIR, was already strongly preferring user@mit.edu
>>>>>>>> styles of email addresses over
>>>>>>>> user@department-or-lab.mit.edu ones before I left about
>>>>>>>> a decade earlier.
>>>>>>>> 
>>>>>>>> In any event, the Authors' Addresses section of
>>>>>>>> draft-rivest-sexp-00 shows the correct current email
>>>>>>>> address, rivest@mit.edu.  Why is the datatracker
>>>>>>>> picking up, and showing on that I-D page, a two
>>>>>>>> decade-old address rather than the one in an I-D posted
>>>>>>>> a couple of days ago?  And, especially assuming that
>>>>>>>> there might be other instances of similar
>>>>>>>> relationships, can this be fixed and fixed more
>>>>>>>> generally than patching that particular page (although
>>>>>>>> that would be good too)?
>>>>>>>> 
>>>>>>>>       thanks
>>>>>>>>        john
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________________
>>>>>>>> ____ Tools-discuss mailing list -
>>>>>>>> Tools-discuss@ietf.org -
>>>>>>>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>>>>> 
>>>>>> 
>>>>>> _________________________________________________________
>>>>>> __ Tools-discuss mailing list - Tools-discuss@ietf.org -
>>>>>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>>>> -- 
>>>>> Jay Daley
>>>>> IETF Executive Director
>>>>> exec-director@ietf.org
>>> 
>>> -- 
>>> Jay Daley
>>> IETF Executive Director
>>> exec-director@ietf.org
>>> 
>>> 
>>> ___________________________________________________________
>>> Tools-discuss mailing list -Tools-discuss@ietf.org
>>> -https://www.ietf.org/mailman/listinfo/tools-discuss
>> 
>> ___________________________________________________________
>> Tools-discuss mailing list - Tools-discuss@ietf.org -
>> https://www.ietf.org/mailman/listinfo/tools-discuss
> ___________________________________________________________
> Tools-discuss mailing list - Tools-discuss@ietf.org -
> https://www.ietf.org/mailman/listinfo/tools-discuss