Re: [Tools-implementation] Fwd: Emacs lock files in rfc rsync

Robert Sparks <rjsparks@nostrum.com> Fri, 05 February 2021 21:50 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: tools-implementation@ietfa.amsl.com
Delivered-To: tools-implementation@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF853A0BED for <tools-implementation@ietfa.amsl.com>; Fri, 5 Feb 2021 13:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Level:
X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATkGTHJmEkeV for <tools-implementation@ietfa.amsl.com>; Fri, 5 Feb 2021 13:50:08 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960E23A0BEB for <tools-implementation@ietf.org>; Fri, 5 Feb 2021 13:50:08 -0800 (PST)
Received: from unformal.localdomain ([47.186.1.92]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 115Lo6fB003593 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <tools-implementation@ietf.org>; Fri, 5 Feb 2021 15:50:07 -0600 (CST) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1612561808; bh=TLcvF/tUPYgs0F3BHC5BcgNXX10s0+fAaaYTAXlLIhI=; h=Subject:To:References:From:Date:In-Reply-To; b=Bds/PTTNjXoQNWg9WLGxMfR2bfaLy+gRwiceqKJFEvGoa/jC4BEgx/XvBi8xp7RS+ 1q1J4hGEAS65Y27xNa1dpnEdVm08v1svWPWv9czdfsWZSw8DWqi08lIIimiO0I3q4J yMVJ/akliH//+cWR/tV7B5m22aoC8MS3d+18wegU=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.1.92] claimed to be unformal.localdomain
To: tools-implementation@ietf.org
References: <4a72d3ce-c790-a190-b3de-f4bd10337e39@amsl.com> <4474bb5c-bb5b-d708-1f8a-de8e90ce0619@amsl.com> <e5bcf5f442ed44a0941577102006d964@cert.org>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <8d6f5894-2d6f-3a96-6c95-079f3a30b727@nostrum.com>
Date: Fri, 05 Feb 2021 15:50:01 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <e5bcf5f442ed44a0941577102006d964@cert.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-implementation/yvEn83tVi8gE3yU8z3WzCqeCJHk>
Subject: Re: [Tools-implementation] Fwd: Emacs lock files in rfc rsync
X-BeenThere: tools-implementation@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Implementation <tools-implementation.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-implementation>, <mailto:tools-implementation-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-implementation/>
List-Post: <mailto:tools-implementation@ietf.org>
List-Help: <mailto:tools-implementation-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-implementation>, <mailto:tools-implementation-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2021 21:50:11 -0000

Specifically this would be the next tools-implementation team meeting.

We don't have one of those scheduled (as we didn't have anything 
immediate to discuss). We can schedule one now.

1600 UTC had been working for us - is it still a reasonable time? If so, 
is Fri 12Feb open for folks.

RjS

On 2/5/21 1:19 PM, Roman Danyliw wrote:
> Hi Glen!
> (looping in Greg)
>
> Concur about adding this as an agenda item for the next meeting  A few related thoughts:
>
> (1) During the community consultation on FTP, parties noted that we should improve our rsync documentation.  All I can find is:
>
> https://www.ietf.org/standards/ids/internet-draft-mirror-sites/
>
> Minimally, I was thinking maybe proving a list of the sync points and what they contain.
>
> (2) https://www.ietf.org/standards/ids/internet-draft-mirror-sites/ currently says "All Internet-Drafts are available via ftp, http, and rsync. This page provided details about these services, including locations and instructions related to I-D mirrors."
>
> -- s/via ftp, http, and rsync/via ftp, https, and rsync/
>
> -- This page only talks about rsync and not the others.  Should we be pointing to https://www.ietf.org/id/ as the reference for HTTPS?
>
> (3) As you noted below that ::rfc is not authoritative, we might want to scrub the following descriptions to annotate which are mirrors of something else (i.e., ::rfc, ::iana, ::iana-timezone) -- say s/Repository of RFCs/Mirror of the repository of RFCs (see also rsync.rfc-editor.org)/
>
> roman@ubuntu:~/ietf$ rsync rsync.ietf.org::
> everything-ftp 	- The entire IETF FTP Archive
> internet-drafts	- The Internet Draft Repository (currently active drafts)
> id-archive     	- The Internet Draft Archive (both active and expired drafts)
> iesg-minutes   	- IESG Minutes
> proceedings    	- Repository of Proceedings
> xml2rfc.bibxml 	The xml2rfc citation libraries
> charter        	- Repository of WG Charters
> concluded-wg-ietf-mail-archive	- Older list text archives
> conflict-reviews	- Repository of Conflict Review documents
> iana           	- IANA assignments
> iana-timezone  	- IANA Time Zone Datatbase (see also http://www.iana.org/time-zones)
> legacy-files   	- Legacy material supporting long-lived URLs
> mailman-archive	- Repository of Mailing List Text Archives
> rfc            	- Repository of RFCs
> slides         	- Repository of Slide Documents
> status-changes 	- Repository of Status Change Documents
>
> (4) We likely also want to discuss the legacy status of ::rfc.
>
> Roman
>
>> -----Original Message-----
>> From: Tools-implementation <tools-implementation-bounces@ietf.org> On
>> Behalf Of Glen
>> Sent: Thursday, February 4, 2021 6:40 PM
>> To: tools-implementation@ietf.org
>> Subject: [Tools-implementation] Fwd: Emacs lock files in rfc rsync
>>
>> Something we should review in our next meeting.   I'll provide the
>> technical details at that time.  (Roman, sorry I forgot to cc you on the original
>> reply, I missed your presence in the header until after I hit send, but this is the
>> same email reply below.)
>>
>> Glen
>>
>> -------- Forwarded Message --------
>> Subject: Re: Fwd: Emacs lock files in rfc rsync
>> Date: Thu, 4 Feb 2021 15:38:02 -0800
>> From: Glen <glen@amsl.com>
>> Organization: AMS
>> To: Eric Rescorla <ekr@rtfm.com>
>> CC: Sandy Ginoza <sginoza@amsl.com>, Alice Russo <arusso@amsl.com>, John
>> R Levine <johnl@taugh.com>
>>
>> All -
>>
>> In the interest of time, I am just grouping everyone together and replying to
>> this thread directly.
>>
>>>> From: Eric Rescorla <ekr@rtfm.com>
>>>> Subject: Emacs lock files in rfc rsync
>>>> Date: February 4, 2021 at 1:06:27 PM PST
>>>> To: RFC Editor <rfc-editor@rfc-editor.org>, Roman Danyliw
>>>> <rdd@cert.org> Hi folks.
>>>> I just rsynced the rfc directory and I see that several of the files have Emacs
>> lock files [0] associated with them:
>>>> lrwxrwxrwx  1 ekr  staff  39 Mar 16  2016 .#bcp-ref.txt ->
>>>> ahagens@rfcpa.amsl.com.16317:1457089460
>>>> lrwxrwxrwx  1 ekr  staff  39 Mar 27  2019 .#rfc-index.xml ->
>>>> ahagens@rfcpa.amsl.com.12369:1551880913
>>>> Aside from just creating problems when someone else tries to edit the files
>> in Emacs, it suggests that you might have some kind of process problem,
>> because this material should be machine generated, and people shouldn't be
>> editing it in a way that the directories are just raw synced to the server.
>>
>> Eric -
>>
>> My apologies, but you are not using the authoritative source for your rsync.
>> You stated that you're using:
>>
>>> rsync.ietf.org::rfc
>> That is the IETF's legacy mirror of RFCs.  I do not refer or recommend it.  It
>> appears to be a legacy configuration, and to have some duplication in it.
>> Moreover, for reasons unknown to me, it is being rsynced without the --delete
>> option, which means it will retain every file it ever saw during any prior rsync.
>> That is why you are seeing those files.  They existed at some interval in the
>> past; they do not exist (on the RFC servers) now.
>>
>> I will raise this with the Tools Implementation Team to see if (a) this behavior
>> should change or (b) the IETF copy should be removed or referred.  Removing
>> files from it, or making changes to it, are not things I can "just do" on my own
>> in my role.  Note that they are working on other, larger projects right now, so
>> this will need some time before it can get attention.
>>
>> In the meantime, I recommend that you change your configuration to rsync
>> your RFCs from rfc-editor.org:: , which is the authoritative source for RFCs.
>> They have a catalog of options, one of which will I hope suit:
>>
>> # rsync rfc-editor.org::
>> everything-ftp  Everything FTP
>> refs            XML references for RFCs (for use with xml2rfc)
>> rfcs            Contents of in-notes including subdirectories std, bcp,
>> fyi, and ien
>> rfcs-text-only  Only the text files from the directories in [rfcs]
>> rfc-ed-all      Entire repository (excluding internet-drafts)
>> internet-drafts Internet Drafts
>> ids-text-only   Only text files from the Internet Drafts mirror
>> rfcs-pdf-only   PDF versions of ASCII RFCs to ensure correct page
>> breaks, etc
>> rfcs-exclude-json       Contents of [rfcs] excluding JSON files
>> rfcs-json-only  Only the JSON files from the directories in [rfcs]
>>
>> In the meantime, the files you referred to, which may exist on the legacy IETF
>> copy, will not be removed, nor will any other changes be made to the IETF
>> copy, until the Tools Implementation Team can carve out time to review this
>> and determine the correct solution.
>>
>> I will send the relevant information to them now, to get this on their radar.
>>
>> Thank you,
>> Glen
>>
>>
>>
>>
>> --
>> Tools-implementation mailing list
>> Tools-implementation@ietf.org
>> https://www.ietf.org/mailman/listinfo/tools-implementation