[Tools-implementation] Building an understanding of the directories at ietf/YYmon
Robert Sparks <rjsparks@nostrum.com> Tue, 01 September 2020 18:39 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 DD7553A0EE6 for <tools-implementation@ietfa.amsl.com>; Tue, 1 Sep 2020 11:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level:
X-Spam-Status: No, score=-2.078 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, HTML_MESSAGE=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 Bo4qP112kkMo for <tools-implementation@ietfa.amsl.com>; Tue, 1 Sep 2020 11:39:29 -0700 (PDT)
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 59EDB3A0EE5 for <tools-implementation@ietf.org>; Tue, 1 Sep 2020 11:39:29 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.15.2) with ESMTPSA id 081IdQrJ001228 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <tools-implementation@ietf.org>; Tue, 1 Sep 2020 13:39:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1598985567; bh=ezEsL1HlvhHuPAAfTR1cn0I/PSA4jWoYyGnO3vVbD4E=; h=To:From:Subject:Date; b=Vqv6sFr1tAYDPLLF2X7/2+OHBA5AXBICYkhYEup5g0pvruqMzSpL+851DghIs+rHg 2aBFlSaV03u50XLwI7z4VBSAAus453YqcagD+vsvQIyOmh3RWSJI/81YBjBE0/ueVO LqIczAbsZeg/LAr6z5PsQVHz50D1+v9IgsO47b1Q=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: "tools-implementation@ietf.org" <tools-implementation@ietf.org>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <aacf32b4-7ae3-b29b-7284-c920c1c0d7df@nostrum.com>
Date: Tue, 01 Sep 2020 13:39:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------9BA3FF7F69BA1A24245FB172"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-implementation/UXHE_exV-gAbvYQbsYUDoOVFRkk>
Subject: [Tools-implementation] Building an understanding of the directories at ietf/YYmon
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: Tue, 01 Sep 2020 18:39:31 -0000
Does anyone already understand what all the directories at /a/www/ietf-ftp/ietf/YYmon (e.g 99nov) are all about? I can make some guesses based on what I see there (I think they were an early effort to organize meeting materials, but it would be better if there were a definitive description of them already lying around. rjsparks@ietfa:/a/www/ietf-ftp/ietf> ls -d [0-9][0-9][a-z][a-z][a-z] 00dec 01mar 03jul 04nov 90dec 92mar 94dec 95jul 97aug 99jul 00jul 02dec 03mar 05aug 91jul 92nov 94jul 96dec 97dec 99mar 00mar 02jul 03nov 05mar 91mar 93jul 94mar 96jun 98aug 99nov 01aug 02mar 04aug 05nov 91nov 93mar 95apr 96mar 98dec 01dec 02nov 04mar 06mar 92jul 93nov 95dec 97apr 98mar The newest file there is: -rw-rw-rw- 1 wwwrun www 279 Aug 1 2001 01aug/opsarea.txt Looking through the http configs, they get served at https://www.ietf.org/ietf/YYmon, and there are a smattering of hits for them in the logs, all from spiders. Some RFCs reference them: rfc1719: > 1. Introduction > > At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide > BOF", on the process and progress of the IPng activities. > > ("IPng" stands for "IP, the next generation". The IPDecide BOF was > chaired by Brian Carpenter. Minutes are available in the IETF > directories, with the file name </ietf/93jul/ipdecide-minutes- > 93jul.txt>.) rfc1752: > [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision > Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt, > August 1993. rfc3238: > [OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda: > "http://www.ietf.org/ietf/00dec/opes-agenda.txt". > Minutes: "http://www.ietf.cnri.reston.va.us/ > proceedings/00dec/toc.htm#P25_256". > > IAB Informational [Page 14] > RFC 3238 IAB Considerations for OPES January 2002 > > [OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes: > "http://www.ietf.org/proceedings/01mar/ietf50-40.htm". > > [OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda: > "http://www.ietf.org/ietf/01aug/opes.txt". Minutes: > "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM". I think these would go into a museum that gets served somewhere, but I don't know if we should force that to continue to be a slice of the www.ietf.org namespace. Is it ok to break those few URLs and enter errata against the RFCs to point to where we move them to? There's no real win to slice parts of https://www.ietf.org/ietf/ out with redirects - I'd like to return everything under that url to be something the website (i.e. wagtail) can use. Otherwise we decide to continue to live with having that chunk of the namespace dispatched to a separate service than wagtail. RjS
- [Tools-implementation] Building an understanding … Robert Sparks
- Re: [Tools-implementation] Building an understand… Russ Housley
- Re: [Tools-implementation] Building an understand… Robert Sparks