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

Roman Danyliw <rdd@cert.org> Fri, 05 February 2021 19:19 UTC

Return-Path: <rdd@cert.org>
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 E454D3A0EF2; Fri, 5 Feb 2021 11:19:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 tBeISQtcVgse; Fri, 5 Feb 2021 11:19:39 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6DD3A0EF1; Fri, 5 Feb 2021 11:19:36 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 115JJTJa048692; Fri, 5 Feb 2021 14:19:29 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 115JJTJa048692
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1612552769; bh=aLYL6lf88PbYCvFQZkrpSEcBKQ74JbB9tK9x9+QEnrw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=OWjdBiUEaY4ThZssWwj90tcBJK3HkRA9Q1+7ihEk93gFjLY4eta0J2RoVMKLintHu EexEjVkUGao0Os6Ye0yhcGBS25Pl5nPFejDG+KkZ+HtAuKJo04I3oBvl/NfMtl92lp Kpe5CUHmqQ8kdu79+/AKZITPKNyEbVAKYmUR3rF4=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 115JJO3J002476; Fri, 5 Feb 2021 14:19:24 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 5 Feb 2021 14:19:24 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Fri, 5 Feb 2021 14:19:24 -0500
From: Roman Danyliw <rdd@cert.org>
To: Glen <glen@amsl.com>, "tools-implementation@ietf.org" <tools-implementation@ietf.org>
CC: Greg Wood <ghwood@ietf.org>, Roman Danyliw <rdd@cert.org>
Thread-Topic: [Tools-implementation] Fwd: Emacs lock files in rfc rsync
Thread-Index: AQHW+08f/AYTJm+qtUmlrNB6YE4Fq6pJ6s3Q
Date: Fri, 05 Feb 2021 19:19:23 +0000
Message-ID: <e5bcf5f442ed44a0941577102006d964@cert.org>
References: <4a72d3ce-c790-a190-b3de-f4bd10337e39@amsl.com> <4474bb5c-bb5b-d708-1f8a-de8e90ce0619@amsl.com>
In-Reply-To: <4474bb5c-bb5b-d708-1f8a-de8e90ce0619@amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.236]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-implementation/lfBRctC0P-EYm4sJ6KDZYAT0pow>
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 19:19:42 -0000

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