From nobody Thu Feb 4 15:40:20 2021 Return-Path: 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 BE35C3A1973 for ; Thu, 4 Feb 2021 15:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 CrPKRnwnKVxw for ; Thu, 4 Feb 2021 15:40:16 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266883A1972 for ; Thu, 4 Feb 2021 15:40:16 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id ED3FE38B4DB for ; Thu, 4 Feb 2021 15:40:14 -0800 (PST) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id DD95F38B4D7 for ; Thu, 4 Feb 2021 15:40:14 -0800 (PST) References: <4a72d3ce-c790-a190-b3de-f4bd10337e39@amsl.com> To: tools-implementation@ietf.org From: Glen Organization: AMS X-Forwarded-Message-Id: <4a72d3ce-c790-a190-b3de-f4bd10337e39@amsl.com> Message-ID: <4474bb5c-bb5b-d708-1f8a-de8e90ce0619@amsl.com> Date: Thu, 4 Feb 2021 15:40:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <4a72d3ce-c790-a190-b3de-f4bd10337e39@amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 23:40:20 -0000 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 Organization: AMS To: Eric Rescorla CC: Sandy Ginoza , Alice Russo , John R Levine All - In the interest of time, I am just grouping everyone together and replying to this thread directly. >> From: Eric Rescorla >> Subject: Emacs lock files in rfc rsync >> Date: February 4, 2021 at 1:06:27 PM PST >> To: RFC Editor , Roman Danyliw >> 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 From nobody Fri Feb 5 11:19:43 2021 Return-Path: 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 To: Glen , "tools-implementation@ietf.org" CC: Greg Wood , Roman Danyliw Thread-Topic: [Tools-implementation] Fwd: Emacs lock files in rfc rsync Thread-Index: AQHW+08f/AYTJm+qtUmlrNB6YE4Fq6pJ6s3Q Date: Fri, 5 Feb 2021 19:19:23 +0000 Message-ID: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 rela= ted 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/ current= ly says "All Internet-Drafts are available via ftp, http, and rsync. This p= age provided details about these services, including locations and instruct= ions related to I-D mirrors." =20 -- s/via ftp, http, and rsync/via ftp, https, and rsync/ -- This page only talks about rsync and not the others. Should we be point= ing 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 sc= rub the following descriptions to annotate which are mirrors of something e= lse (i.e., ::rfc, ::iana, ::iana-timezone) -- say s/Repository of RFCs/Mirr= or 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 draft= s) 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/ti= me-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 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 >=20 > 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 t= his is the > same email reply below.) >=20 > Glen >=20 > -------- Forwarded Message -------- > Subject: Re: Fwd: Emacs lock files in rfc rsync > Date: Thu, 4 Feb 2021 15:38:02 -0800 > From: Glen > Organization: AMS > To: Eric Rescorla > CC: Sandy Ginoza , Alice Russo , John > R Levine >=20 > All - >=20 > In the interest of time, I am just grouping everyone together and replyin= g to > this thread directly. >=20 > >> From: Eric Rescorla > >> Subject: Emacs lock files in rfc rsync > >> Date: February 4, 2021 at 1:06:27 PM PST > >> To: RFC Editor , Roman Danyliw > >> Hi folks. > >> I just rsynced the rfc directory and I see that several of the files h= ave 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 b= e > editing it in a way that the directories are just raw synced to the serve= r. >=20 > Eric - >=20 > My apologies, but you are not using the authoritative source for your rsy= nc. > You stated that you're using: >=20 > > rsync.ietf.org::rfc >=20 > 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 --de= lete > option, which means it will retain every file it ever saw during any prio= r 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. >=20 > I will raise this with the Tools Implementation Team to see if (a) this b= ehavior > should change or (b) the IETF copy should be removed or referred. Removi= ng > 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 n= ow, so > this will need some time before it can get attention. >=20 > In the meantime, I recommend that you change your configuration to rsync > your RFCs from rfc-editor.org:: , which is the authoritative source for R= FCs. > They have a catalog of options, one of which will I hope suit: >=20 > # 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] >=20 > 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 th= is > and determine the correct solution. >=20 > I will send the relevant information to them now, to get this on their ra= dar. >=20 > Thank you, > Glen >=20 >=20 >=20 >=20 > -- > Tools-implementation mailing list > Tools-implementation@ietf.org > https://www.ietf.org/mailman/listinfo/tools-implementation From nobody Fri Feb 5 13:50:12 2021 Return-Path: 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 ; 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 ; 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 ; 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 ; 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> From: Robert Sparks Message-ID: <8d6f5894-2d6f-3a96-6c95-079f3a30b727@nostrum.com> Date: Fri, 5 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 >> Organization: AMS >> To: Eric Rescorla >> CC: Sandy Ginoza , Alice Russo , John >> R Levine >> >> All - >> >> In the interest of time, I am just grouping everyone together and replying to >> this thread directly. >> >>>> From: Eric Rescorla >>>> Subject: Emacs lock files in rfc rsync >>>> Date: February 4, 2021 at 1:06:27 PM PST >>>> To: RFC Editor , Roman Danyliw >>>> 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 From nobody Fri Feb 5 14:38:18 2021 Return-Path: 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 15C853A0D2B for ; Fri, 5 Feb 2021 14:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 Tl0vn-i68lSi for ; Fri, 5 Feb 2021 14:38:09 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09F53A0D55 for ; Fri, 5 Feb 2021 14:38:07 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id D630B38AEBA for ; Fri, 5 Feb 2021 14:38:06 -0800 (PST) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id C800A38AEA1 for ; Fri, 5 Feb 2021 14:38:06 -0800 (PST) To: tools-implementation@ietf.org References: <4a72d3ce-c790-a190-b3de-f4bd10337e39@amsl.com> <4474bb5c-bb5b-d708-1f8a-de8e90ce0619@amsl.com> <8d6f5894-2d6f-3a96-6c95-079f3a30b727@nostrum.com> From: Glen Organization: AMS Message-ID: Date: Fri, 5 Feb 2021 14:38:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <8d6f5894-2d6f-3a96-6c95-079f3a30b727@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 22:38:18 -0000 On 2/5/2021 13:50, Robert Sparks wrote: > 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. I cannot do anytime Wed-Fri this week. My electric company has decided they need to dig up the street I live on, and I expect to be without power here on Wed, Thu and Fri (Fortunately only during the day, but, still.) I've already had to "book the office" for Wednesday owing to critical events that day, not comfortable with later in the week either. Monday or Tuesday of the following week would be better for me. That said, our one item is not particularly urgent and we are still pushing on larger projects, so I did not mean to imply that a meeting was urgent. I think we can wait until after 110 safely. Glen From nobody Fri Feb 5 14:46:18 2021 Return-Path: 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 2D7B43A0CEE for ; Fri, 5 Feb 2021 14:46:17 -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 XN0ND3cWw62N for ; Fri, 5 Feb 2021 14:46:14 -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 5E97E3A0CED for ; Fri, 5 Feb 2021 14:46:14 -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 115MkCYA023350 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 5 Feb 2021 16:46:12 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1612565172; bh=3HBShVLdD9JNrZN2kUW/YHT+TDnxt+SQagqBUC1VyYM=; h=Subject:To:References:From:Date:In-Reply-To; b=PBNcwTmI+ipXDkGDNF5PdJIFHuFmuiI5dHMmKUGyRz6WXG3BJE4u0jxmcDLAW3MVm KTWClp7WlHMOHXRkbnwSbzvFtqjMbrWGbujZBCfpBq7jDck/MtOlkjBn5UdmDpVuJ9 CirJDJAFo2ERqcKeY6BA9tFxzpOT7oOrx259iITE= 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> <8d6f5894-2d6f-3a96-6c95-079f3a30b727@nostrum.com> From: Robert Sparks Message-ID: <9a13bed3-0e29-c82d-e951-4e33c0a33f70@nostrum.com> Date: Fri, 5 Feb 2021 16:46:06 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 22:46:17 -0000 On 2/5/21 4:38 PM, Glen wrote: > On 2/5/2021 13:50, Robert Sparks wrote: >> 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. > > I cannot do anytime Wed-Fri this week.  My electric company has > decided they need to dig up the street I live on, and I expect to be > without power here on Wed, Thu and Fri (Fortunately only during the > day, but, still.)  I've already had to "book the office" for Wednesday > owing to critical events that day, not comfortable with later in the > week either. > > Monday or Tuesday of the following week would be better for me. > > That said, our one item is not particularly urgent and we are still > pushing on larger projects, so I did not mean to imply that a meeting > was urgent.  I think we can wait until after 110 safely. Ok - will defer for the moment. > > Glen > From nobody Tue Feb 9 10:02:15 2021 Return-Path: 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 5E6783A10B1; Tue, 9 Feb 2021 10:02:13 -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 OEFVmOiOVQxZ; Tue, 9 Feb 2021 10:02:10 -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 204383A10A9; Tue, 9 Feb 2021 10:02:09 -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 119I28sC027400 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 9 Feb 2021 12:02:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1612893729; bh=XZ31QNl9DiyekZ4aRXPvwGZ6YKkk3tr55seP8oQ3kaY=; h=Subject:To:References:From:Date:In-Reply-To; b=Dwj9iHfzO1L9/RpBxQqprSVRJVcs6Hhrs8JUsVb+D0syDccEcWdpNbET9mwgNhXgr cKM3Ci2+hUS2koqdXdMuDhtILBcV311ubhjmn7EyNl4LENeyCEyvKeWdCgWxmVD6YP 3XkW6/VdLt/2GUJdh6MDB2jTkesNvC7RQRjhlSgo= X-Authentication-Warning: raven.nostrum.com: Host [47.186.1.92] claimed to be unformal.localdomain To: tools-implementation@ietf.org, Greg Wood References: <4a72d3ce-c790-a190-b3de-f4bd10337e39@amsl.com> <4474bb5c-bb5b-d708-1f8a-de8e90ce0619@amsl.com> From: Robert Sparks Message-ID: <5a46fb9f-9e9c-74e1-eb5c-6651a509ab21@nostrum.com> Date: Tue, 9 Feb 2021 12:02:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 18:02:13 -0000 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. Hi Roman - how is that not the list you retrieved below from rsync.ietf.org:: ? Is the issue that the descriptions are not detailed enough? > > (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? I think we should always point to the id archive unless we are _specifically_ trying to say "active drafts". So the link should be https://www.ietf.org/archive/id/ (which is a brutal beast to retrieve). > > (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 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 >> Organization: AMS >> To: Eric Rescorla >> CC: Sandy Ginoza , Alice Russo , John >> R Levine >> >> All - >> >> In the interest of time, I am just grouping everyone together and replying to >> this thread directly. >> >>>> From: Eric Rescorla >>>> Subject: Emacs lock files in rfc rsync >>>> Date: February 4, 2021 at 1:06:27 PM PST >>>> To: RFC Editor , Roman Danyliw >>>> 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 From nobody Tue Feb 9 10:53:48 2021 Return-Path: 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 DE56B3A112A for ; Tue, 9 Feb 2021 10:53:46 -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 8as2sqEZBpbb for ; Tue, 9 Feb 2021 10:53:44 -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 23E803A1129 for ; Tue, 9 Feb 2021 10:53:44 -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 119IrgEC045308 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 9 Feb 2021 12:53:43 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1612896823; bh=tiMF8EHzYiARDW3jQ3JCj5/hO1A+IUURJeHFdLsyKOc=; h=Subject:To:References:From:Date:In-Reply-To; b=PvC7pnBJRIaIKE9Z9Slc5SCwg888eX6g4iHfPEpUFMmFrcBi9Dl0HzhdCWTgxri+N qY4dbTS/5iajKUcZsL1zKyhQi1Jl+YY94jIURExnZdD5w2Fo29ZFk7pgWQ6DROYUvT 8fEgdZkWlxCt5SRPDJkgWrWpTw0TFAKiqsEoYLao= 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> From: Robert Sparks Message-ID: Date: Tue, 9 Feb 2021 12:53:37 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <4474bb5c-bb5b-d708-1f8a-de8e90ce0619@amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 18:53:47 -0000 For the short term, I propose that we delete and resync what's at our ::rfc sync point so it matches the rfceditor exactly. Does anyone know of a reason not to do that? We can then discuss removing it as an exposed sync point. RjS On 2/4/21 5:40 PM, Glen wrote: > 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 > Organization: AMS > To: Eric Rescorla > CC: Sandy Ginoza , Alice Russo , > John R Levine > > All - > > In the interest of time, I am just grouping everyone together and > replying to this thread directly. > >>> From: Eric Rescorla >>> Subject: Emacs lock files in rfc rsync >>> Date: February 4, 2021 at 1:06:27 PM PST >>> To: RFC Editor , Roman Danyliw >>> >>> 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 > > > > From nobody Tue Feb 9 10:55:53 2021 Return-Path: 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 4A1F03A1132 for ; Tue, 9 Feb 2021 10:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 C_ZNLdiQ_50t for ; Tue, 9 Feb 2021 10:55:47 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8153A1130 for ; Tue, 9 Feb 2021 10:55:47 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 4ACED38AEB9 for ; Tue, 9 Feb 2021 10:55:46 -0800 (PST) Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id 381A838AEA1 for ; Tue, 9 Feb 2021 10:55:46 -0800 (PST) To: tools-implementation@ietf.org References: <4a72d3ce-c790-a190-b3de-f4bd10337e39@amsl.com> <4474bb5c-bb5b-d708-1f8a-de8e90ce0619@amsl.com> From: Glen Organization: AMS Message-ID: Date: Tue, 9 Feb 2021 10:55:46 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 18:55:51 -0000 Agreed on all counts from my point of view. Glen On 2/9/2021 10:53, Robert Sparks wrote: > For the short term, I propose that we delete and resync what's at our > ::rfc sync point so it matches the rfceditor exactly. > > Does anyone know of a reason not to do that? > > We can then discuss removing it as an exposed sync point. > > RjS > > On 2/4/21 5:40 PM, Glen wrote: >> 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 >> Organization: AMS >> To: Eric Rescorla >> CC: Sandy Ginoza , Alice Russo , >> John R Levine >> >> All - >> >> In the interest of time, I am just grouping everyone together and >> replying to this thread directly. >> >>>> From: Eric Rescorla >>>> Subject: Emacs lock files in rfc rsync >>>> Date: February 4, 2021 at 1:06:27 PM PST >>>> To: RFC Editor , Roman Danyliw >>>> >>>> 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 >> >> >> >> >