Re: [tao-discuss] [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 01 April 2022 13:03 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: tao-discuss@ietfa.amsl.com
Delivered-To: tao-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA603A21E0; Fri, 1 Apr 2022 06:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.606
X-Spam-Level:
X-Spam-Status: No, score=-9.606 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DFruaY52; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DmRO9Z9q
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 LR9iybUMXtxq; Fri, 1 Apr 2022 06:03:07 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE753A21DB; Fri, 1 Apr 2022 06:03:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19198; q=dns/txt; s=iport; t=1648818187; x=1650027787; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=93ww8M9NKp1JhNr3GI89EVx2d9MgI/6cwWHkYeWorIw=; b=DFruaY52sIXWUuTxv993ZOaOk3coGqiBbk3xa+ivlh9QyhpjjG/6seXn N+QfmAO2eQoY4VlXnxeLeoI9o+cmQ/4RM0ss4A7hfjejl061787yOG9tE DhdDyuUheEHMiLnaFIc6fuij6kEeD5Wkz8C/GY1+msvgmH1Q/3F7ZadtT s=;
X-IPAS-Result: A0ALAADP9kZimIsNJK1aHAEBAQEBAQcBARIBAQQEAQFAgUYHAQELAYFRLih+WjdEhFSDSgOEWWCFEIMCA4sShTKKdIEuFIERA1QLAQEBDQEBLAsMBAEBhQcCF4RAAiU0CQ4BAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEJFAcGDAUOECeFaA2GQgEBAQEDAQEQEREMAQEsBgUBCwQCAQYCEQQBAQECAh8EAwICAh8GCxQBCAgCBA4FCBqCYgGCZQMuAQ6TCo82AYE6AoEOiRF6gTGBAYIIAQEGBASFCw0LgjgJgRAsAYMQgwADWE2HFSccgUlEgRVDgWaBAT6CIUIBAQEBgUQcFYMDN4IMIphGDwsBLS0GCAcZCgwbCwEDMQsEAw4CFAw7GCUFAiYZcCkDkX4LNgWCVUaKJoNEnAJrCoNJixSObIYZFYN0gU+KaIZdkUaWAV2NGINVkDwqBwEYhG8CBAIEBQIOAQEGgWF1gSBwFTuCaQlIGQ+BG40FDA0JFW8BAoJJRoROhUp1AjYCBgEKAQEDCZEDXQEB
IronPort-PHdr: A9a23:TnByPh/FEA5CZf9uWCXoyV9kXcBvk7n3PwtA7J0hhvoOd6m45J3tM QTZ4ukll17GW4jXqpcmw+rbuqztQyoMtJCGtn1RfJlFTRRQj8IQkkQpC9KEDkuuKvnsYmQ6E c1OWUUj8Wu8NB1eGd31YBvZpXjhhQM=
IronPort-Data: A9a23:qYb1MaiNVSEeUu9/SMQIx8SZX161lRAKZh0ujC45NGQN5FlHY01je htvCj2FOv7YZDPwfd9+YIS/oBgEu5aAnNdhSlZk+S5mRihjpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKkYAL/En03FFcMpBsJ00o5wbZl2tcw27BVPivU0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pDTU2FFEYUd6EPdgKMq 0kv+5nilo/R109F5tpICd8XeGVSKlLZFVDmZna7x8FOjzAazhHe3JrXO9Iial1nhzywout85 /Ngk4GBRicqDIPTzbF1vxlwS0mSPIVP/LvBZHO4q8HWkQvNcmDnxLNlC0Re0Y8wo7ksRzoQs 6VDbmlWP3hvhMruqF6/YvFwhtkpIdP3FIgeoXpnizreCJ7KRLiTE/2UuI4FhGZYasZmDO3Ed +9HdANTQg3bQT5WGAoIUcgvk7L97pX4W2QI9A3KzUYt2EDPxQs03Ln2O8fOYfSLSNlb2EGCq Qru/mn0D1QbOcCRjDGC9Wigru7CgS29X5gdfJWi+PUvgVuPy3YeEwE+T1Ww5PS1i1K5QZRYM UN80jUhpqg79VawZtjwQxP+p2SL1jYWQdtZFas3rgqE0LLZ5RqUHEALSzdAbJots8peeNAx/ laNm9WsDjt1vfjLD3mc7byT6zi1PED5MFPuewc6ThE179Danbo+oTTiaMtSH462vPPqTGSYL y+xkAAygLAajMgu3qq9/Ezajz/EmnQvZlNojukwdj/5hj6VdLJJdKTzsgGCsqgowJKxCwjf4 idVwqBy+chXVcnlqcCbfAka8FhFDd6sNDnRhzaD9LF+qmz0oBZPkW2siQySyW9gNsICPDTue kKW50Va5YRYOz2haqofj2ON5yYCkPWI+TfND628gj9yjn5ZL1TvEMZGPhT44owVuBJw+ZzTw L/CGSpWMV4UCL580B29TPoH3Lkgy0gWnD2PFc+mlkj/jurDPxZ5rIvp1nPTPojVC4vZ/m3oH yp3a6NmNj0GCrSlO3mLmWLtBQlQcidT6W/KRzx/L77ffVUO9JAJAP7KyrRpYJ1+g6lQjY/1E oKVBCdlJK7ErSSfc22iMyk7AJu2BMoXhS9rbEQEYAfzs1B+MNnHxPlELfMfI+J4nNGPONYpF ZHpje3aXKQWItkGkhxABaTAQHtKL0rz31vUb3v4OFDSvfdIHmT0xzMtRSO3nAFmM8Z9nZFWT 2GIvu8Dfac+eg==
IronPort-HdrOrdr: A9a23:iW6dCKuDPA1tq5LrcuwfB8Co7skC14Mji2hC6mlwRA09TyXGra 6TdaUguiMc1gx8ZJh5o6H+BEGBKUmskaKdkrNhQ4tKOzOW9ldATbsSorcKpgeAJ8SQzJ8k6U /vGZIOc+EYYWIK7/oSpTPIb+rIo+P3sZxA592utUuFJDsCA8oLgmcJaTpzUHcGOTWubqBJc6 Z0k/A33gZIDk5nCPhTaEN1OtTrlpnurtbLcBQGDxko5E2lljWz8oP3FBCew1M3Ty5P6a1Kyx mEryXJooGY992rwB7V0GHeq75MnsH699dFDMuQzuAINzTXjBqybogJYczAgNl1mpDs1L8Zqq iJn/4SBbU115oXRBDynfLZ4Xik7N/p0Q669bbXuwq6nSWzfkNKNyMIv/MoTvKe0Tt6gDm5u5 g7gl5wcPFsfEn9dW3Glqv1fgAvmUyurXU4l+kPy3RZTIsFcbdU6ZcS5UVPDf47bWjHAa0cYa FT5fvnlb1rmJKhHgfkl3gqxMbpUmU4Hx+ATERHssuJ0yJOlHQ8y0cD3sQQknoJ6Zp4EvB/lq j5G7UtkKsLQt4dbKp7CutEScyrCnbVSRaJNG6JO1zoGKwOJnqIoZ/q57c+4v2sZfUzvdYPsY WEVEkduX85ekroB8HL1JpX8grVSGH4RjjpwtE23ekxhlQ9fsucDcSuciFaryL7mYRsPiTyYY fGBK5r
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.90,227,1643673600"; d="scan'208";a="880659509"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2022 13:03:04 +0000
Received: from mail.cisco.com (xfe-rcd-003.cisco.com [173.37.227.251]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 231D32Hr024056 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2022 13:03:03 GMT
Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Fri, 1 Apr 2022 08:03:02 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Fri, 1 Apr 2022 09:03:01 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=odn74nq2hFYv2hn/v6iwURJbrYgvrFMoFy6OdIPym+LwSdUFSs9wAyBq8VfEbnUqozZLaqaDj6GeD7fAJvdx/vur0DCAye5gEb+9DAI7aYStM4THpig3IrVjzkF9D5GbV2xiFQgF6aqhRcx5hvN/rVIC/RNTyue0JzWGh4EkMpNwQwG5VyfVaW1vq8EV/mBPf/bw6j71XY33UNpOvF7RAoo0igdYos6sAz2+5I4XRMckhF31vLF2giyOzhxtsij6Af60HORcOI4Cgzf5mS0tVcrGLR6czWHEag92/iywQSwm5BJB7rCOlI96QbV9R/1ML0s/dihXwG/Z7xR1j1iZrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=93ww8M9NKp1JhNr3GI89EVx2d9MgI/6cwWHkYeWorIw=; b=D+NUGT0tZ2ZIZDVaPUH8d5W4rCFkFWnVjPz4QLb+xmXhhsedcqeu6wnhj6nsNwSOAYE2MILM2/pdBf8W12xNh7Id40r2n0ubHFtCGBTZqA4q3qWx+RRUjcscN6A+CZsCKhIYZBQb9xPYOAXhO8loka3T+LGcmcNp4QC5Xc84QyjecY/fxxvQrN80cusLmfl62vpX3vqGMBh1Cc8bzOderMLoo8LgaBf1TDRBlsI6SWzqIhD5Duk+FErTdzGInEqEXlaT9p6zlzcSSXHNYty+klbgnR8vuWaKHo2v7iUOaGjeW3VJaRt+K0e5vgaoINqrRM3CEm4uDpdaNWMzMZMAtw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=93ww8M9NKp1JhNr3GI89EVx2d9MgI/6cwWHkYeWorIw=; b=DmRO9Z9qej1o9+t789KE7PSG4AvrwUItG4yGpXMAm2mWpb4IDBRzmSfH0sV5tKRmfAA4g3yGKatf/SjszzOR62oYoJ7FEFUaHXG6Ou6EBEpsbFY3DK3pa1H0njDtd4D7gI1HYkjnMLzagc4V3kEIsyXgPDiLwH2QKEww6MmU4RU=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by BL0PR11MB3265.namprd11.prod.outlook.com (2603:10b6:208:6a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.29; Fri, 1 Apr 2022 13:03:00 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888%5]) with mapi id 15.20.5123.026; Fri, 1 Apr 2022 13:03:00 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: "wgchairs@ietf.org" <wgchairs@ietf.org>, "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>, "<ieee-ietf-coord@ietf.org>" <ieee-ietf-coord@ietf.org>, "tao-discuss@ietf.org" <tao-discuss@ietf.org>
Thread-Topic: [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)
Thread-Index: AQHYQDXZXj3vIG5yVUq7ezFtdHQ/7KzP7xAAgAAfBKCAAA2ugIAAPdQAgAABhwCABPihgIAFuKUA
Date: Fri, 01 Apr 2022 13:02:52 +0000
Deferred-Delivery: Fri, 1 Apr 2022 13:02:12 +0000
Message-ID: <CO1PR11MB48814EB53AE84515F5D2C03FD8E09@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <Yj2d4DJMFWJOxoZa@faui48e.informatik.uni-erlangen.de> <317196df-3363-36c9-2421-02d9e229f664@joelhalpern.com> <CO1PR11MB488130CFF42A9F309AE1E212D81A9@CO1PR11MB4881.namprd11.prod.outlook.com> <95b5dab0-3eb5-536d-85fc-d428f26364ed@joelhalpern.com> <CABcZeBOSMRffY6cXjwn7A6d=JWDJmmBrgHxiPD-XRMTMazOjLw@mail.gmail.com> <CO1PR11MB48812B0C5B88C190FB4A28ECD81D9@CO1PR11MB4881.namprd11.prod.outlook.com> <7042bc99-5d14-993c-198b-1080b4ff5636@gmail.com>
In-Reply-To: <7042bc99-5d14-993c-198b-1080b4ff5636@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1efb7d19-5275-492a-7c43-08da13dff320
x-ms-traffictypediagnostic: BL0PR11MB3265:EE_
x-microsoft-antispam-prvs: <BL0PR11MB326594512E1B99E9B520E210D8E09@BL0PR11MB3265.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OCrXdJmjdY40SOu4mr1TSOSf6VAXkUcq1yhq59di9Vfepgcns5Zu+dN3JOivCSWS4usZQs3w7OE4C6WYcz/xgpgMFYS3+6UggP5xLFPuYVdIleXw38aSQ0gwtZZ2T4mkhrqLM0eq54FoRnr8UT6FxVqpCNEFB5wYo+0VsDR7iuzXZcVek9sxratOUl75/keFLyCJoznfMHyDBnq9WEoIU1YaLE+AFd3KyN1o7o98MB7LntmRX7tZpARxZGEydOjQOfMsgzvDaDWX1b7PyAcOX4drLS+54f8RQzr9FrX9Kb+X+3mkJIuEnaLVMrczJzescHrE463mCdrXZ6DLWiCpN0NteNOFsyv5G1pJyReCTtXbiUOqvjan0pmsrQxYxPVxjj+9YOPAhfK3/VIzAI3C7gfnkcoG7cSFnnJ6+PcWOX6NQ2iODQ3b89z+JFfQly6h+if7pPz5rv3kC0sAwjExZ4QCO2IKndAvrjl6IE2MlU0zZ9+zP5qGKYFIGrVSdodHdPXfJbmZRu38O0Iqxif38KIrc85SBAoih7kMljB9kD3s4SK01dSYFfxT/PAxcSa2a8We8NbTsrbMwRf0ZBhpmpwdr8+n+OLbVDXmfGVbA/s4WwUk74iG0GKEuLmTIX5zACYcvX2k36P6C7P0aAbB+ckJHkZQyUM1impVA61I5MBoXa4OTJyOsWH4XOFavpdx2z/+vZySD7Fx2STzJw8vl2+CfqJK1bA9lo26pR6NTPdQYIDrlgh8RxPt4DkFInhxxr4QD9K82C9oqQZCDKB60bd8bZuR1W0I3itfAjt2P5iwIh/VDi5nLuXGhLstXPTjAZW1fQqzt2wmM6EzOgM1LGsRdeu6gcY8CKAlZVhgP+g=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(38100700002)(66574015)(38070700005)(26005)(186003)(52536014)(2906002)(30864003)(8936002)(5660300002)(55016003)(33656002)(6506007)(53546011)(4326008)(66476007)(64756008)(76116006)(8676002)(66946007)(316002)(7696005)(66556008)(66446008)(9686003)(508600001)(83380400001)(6666004)(122000001)(86362001)(966005)(6916009)(71200400001)(54906003)(498844002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: p7ArIoO1YTNfezXzQOMCCZ7XKvGl8LiljxKH7bXY1SPwcgpeC48qZscRnHy/Sn/dYWOkfG4tiquYDNloCRHjzRGu+RlhBqoMbzPVcgzghv5u0NBOahb1du6frRkwb5nmKRv/TbuZy7zZjQeAo84Id3U+DpYJitv849hx4eiYJ9K+wr3zOB2Ls8ue8rUtFo2RKC2lSwnkZlh+j+AV4p0eQ5QsKZ+zwwCqZ42RjbvQHri31NtbokDgvAhHbH46I6fQGQuFG7x4Eo3xAyb+1xhuEwTvOY+VztfKk+ybu06V/EYjYcPvnere1haau1L3tH+xnsZxdCj6RVav65aFi/RpcZu46h7Wm3nArlAXLol1FUzxEmBDipyGA4AHbUd7nWDa9nxHzg9zc7+o/9pt6U22JZrFPa7wuAFCAQ5Exy9F2XZulmpWDcPruNA6wP5dUWybiQhysROUrrzWvdDYaGtXpthcHy6rgZOJgqkR8Z/bepjwk1Tg+DUuy7Y/QGnb3il0zoDPV1W5CmYu03/w9gSjB2G8kooKKQXJkDSQKBNzT4stRVmChD9EAOMmiYgtAU65Eys3+3V+rZgQt/+ebQNxj7kbsXGBfHQfB/ZXIzIamOoBG+jzZy0OiFtHOHhqSYJIdqAM7L+pr+6kM34FGdBxPvErqZ3MtZO2gaWZoj1IfFfyYYSo3VWYokFuLZ7FQGcPAqhydXVq9ZBLaXkbklA0CjqjI+r2KUji0EreJH+kbZS2OFnAOCPhMj5yeTLqKTh+wvmS7Vz/wiHW1i2l+uJUQZ4FkPHVFb3M480+PwDJr3cgCgDPYaYPwZMGyVsgbVQWehBO4OnjNqgSU/2x2aaOy/YukI2z54+qBHXu4OH4jRNhNLMg7L6qb9xopjmBkbEiDPnHqABikLMAVV6Q+cQ9lWPs0xARJ+GV9x0mFaYypQ9ADhzHsxlECnzCqCng/vG8xiLd04WZhpE93GIVLjg/WjAcqaZxckgmmqArUKE8R/hOhxXWBUBq9n+lrD1xdIhIkb/bsgUZJ67QBnq9U2RYvxZPGKc2McOW+YG+HoQxmPBe/lQVbQcxi2xqTJo/svqQ86h1J0oukupCuszWWq4AKc9D8VIxaMyDJ+JELhAXV0nY1B8y69rv3Qhx9J/aNxHj7nUbQhzCXuZxlwR1xBTf2OBlhrQR4VvqThaUpn9k2nhrOlShzC2JiMjBMyzgkWyJYNQQw1AdCuaPCZ2fLxAQeqUEvD8y+fOJtYAR/y/FJ65iNl3HxlAnIyaxOAvxoZEmEr9X4cN5bzoxLFvoXeVmUJdmUAoElwUgvCsKxs0bCNlONh8cg5+DwIVBPt+oyp89Gd4+xZ6DTeRXofdXo1vnbTZi88jjq7ATAMsoyDsedlxOxhzauzh1u/p+fN5sDzAZdYozHgJRRv8rWQItl6GGmKg+mFh1hpDsKN06p2jEKhUdxYZtXkLoARWQ/iWjy/X+cJRhxAkbSm1GBL0e8/1RHNSCqMLFcQwgU/4r/rudMimAFnKuuM5Wm+VDGZtci2Vjp4/dKNkZoGdFbADU14kPwTmISmwBOR3Zvtf/KrmUZPv0FGyz/AoLaoUzxxp8/jmH+FiC4BIGmH7tSdNwmJAqfkJYlABZd5M+QoZt/ActD+c6jVZcDE+zXSR3Pw5iSEttJCR89z5/c7WE/zKYR3MY3b/+Gq6ooKdiI2sITLeKwGYnOTjyn1fdegZA34AWxYLDVyNUGX3rh4ZpSwVT+aUXTw==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1efb7d19-5275-492a-7c43-08da13dff320
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2022 13:03:00.2880 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: szl0OAWlDk6im+vtejfbbF8EpP0+fUOOvdd7L8Jur4zTeciPgXFYi9UMtWqYzEriz0K4/+R1XHJbuJDEKnL6BQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3265
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.227.251, xfe-rcd-003.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tao-discuss/qJAumQFLp6D9wiFZFyvfZKqUwHk>
Subject: Re: [tao-discuss] [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)
X-BeenThere: tao-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of the Tao of the IETF <tao-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tao-discuss>, <mailto:tao-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tao-discuss/>
List-Post: <mailto:tao-discuss@ietf.org>
List-Help: <mailto:tao-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tao-discuss>, <mailto:tao-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Apr 2022 13:03:13 -0000

Hello Brian:

Thanks for caring :) All good, but the text I'm concerned with has not evolved since RFC 3160:

https://www.ietf.org/about/participate/tao/#6-3 : "
Under no circumstances should an Internet-Draft be referenced by any paper, report, or Request-for-Proposal, nor should a vendor claim compliance with an Internet-Draft".	
"

One last-minute editor of 802.11md removed text on IPv6 because one IETF reference was still a draft. Yes, I could have asked for a early assignment and he may have been fooled; or he may have found that the RFC did not exist on our shelf. He did not ask, and any fashion per our own wording he did the right thing.

I'm following your advice to copy tao-discuss. My question to tao-discuss is we have text here that we are not following in our own standards, which can informatively reference I-Ds, though an STD track RFC probably holds some status vs "any paper".

Also copying the IETF IEEE coordination; the status of I-D references could be something to agree upon at least between IETF and IEEE.

Keep safe;

Pascal

> -----Original Message-----
> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Sent: lundi 28 mars 2022 23:24
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Eric Rescorla
> <ekr@rtfm.com>; Joel Halpern Direct <jmh.direct@joelhalpern.com>
> Cc: wgchairs@ietf.org; rfc-interest@rfc-editor.org
> Subject: Re: [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re:
> Chair/datatracker tracking expired WG documents ?)
> 
> Pascal,
> 
> On 28-Mar-22 18:35, Pascal Thubert (pthubert) wrote:
> > Hello Eric,
> >
> > The initial question was about referencing I-Ds and that focus seems now
> lost.
> >
> > If I may return to subject: The issue is with RFC 3160 that says:
> >
> >        An Internet Draft is NOT a means of "publishing" a
> > specification;
> >        specifications are published through the RFC mechanism ...
> >        Internet Drafts have no formal status, and are subject to
> > change
> >        or removal at any time.  Under no circumstances should an
> > Internet
> >        Draft be referenced by any paper, report, or
> > Request-for-Proposal,
> >        nor should a vendor claim compliance with an Internet Draft.
> >
> > Many people outside the IETF read this literally. Never reference an I-D.
> Though we do reference I-Ds in our own RFCs. This is inconsistent.
> 
> We cite them as "work in progress" and as informative references, in
> accordance with RFC 2026, which is the actual origin of the above text. In
> RFC 2026 it is immediately followed by the "work in progress" exception, so
> there is no real inconsistency. (Though for the full story one should also
> consult BCP97.)
> 
> Also, RFC 3160 was obsoleted by RFC 4677 which was obsoleted by RFC 6722.
> The valid Tao is now https://www.ietf.org/tao.html. If you think the Tao
> should also mention the "work in progress" exception, write to tao-
> discuss@ietf.org.
> 
> >
> > The ask is that we reword RFC 3160 to say something like : “ANY
> normative document inside or outside the IETF MAY reference non-normatively
> an I-D but MUST NOT reference an I-D normatively.”
> 
> (We don't use normative language in the Tao.)
> 
> > I fail to see why non-normative document should be barred to reference I-
> Ds. Many times they do and we have no control nor say on that. We make it
> possible by retaining the drafts on the datatracker.
> 
> This is not forbidden at all. In fact, non-normative references to I-Ds are
> allowed in normative documents too.
> 
> > Sometimes someone raises the issue with the status of I-Ds and we get into
> endless discussions, I faced that again recently at ETSI.
> 
> Don't people *read* the status section of such I-Ds? It is perfectly
> explicit. I really can't see anything unclear in 'It is inappropriate to use
> Internet-Drafts as reference material or to cite them other than as "work
> in progress."' Why is that hard to understand?
> 
>     Brian
> 
> >
> > What so you think?
> >
> > Pascal
> >
> > *From:* Eric Rescorla <ekr@rtfm.com>
> > *Sent:* vendredi 25 mars 2022 18:23
> > *To:* Joel Halpern Direct <jmh.direct@joelhalpern.com>
> > *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com>; wgchairs@ietf.org;
> rfc-interest@rfc-editor.org
> > *Subject:* Re: [rfc-i] 3rd party SDO cross-referencing of IETF work (was:
> Re: Chair/datatracker tracking expired WG documents ?)
> >
> > I agree with Joel. This will necessarily be incomplete (I suspect very
> incomplete).
> >
> > If we were to do anything here it would be to ask if there was some action
> we could take to get Google Scholar or the like to accurately detect this
> case and note it.
> >
> > -Ekr
> >
> > On Fri, Mar 25, 2022 at 6:42 AM Joel Halpern Direct
> <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>> wrote:
> >
> >     I consider that tracking in-pointing references is not a task we want
> to
> >     take on.
> >     Unless you are running something like ResearchGate, it is almost
> >     impossible to get right and current.
> >
> >     Making sure other folks point to the right thing is not something we
> can
> >     do.  Heck, the bigger issue of getting folks to make changes when we
> >     obsolete RFCs is outside our ability.
> >
> >     Yours,
> >     Joel
> >
> >     On 3/25/2022 8:56 AM, Pascal Thubert (pthubert) wrote:
> >     > Hello Joel
> >     >
> >     > You got the proposal wrong.
> >     >
> >     > The proposal was:
> >     >
> >     > ANY standard in or out IETF MAY reference non-normatively an I-D but
> MUST NOT reference them normatively. Non-IETF standards SHOULD register their
> use of I-Ds, be it to be informed if the draft becomes RFC so they can decide
> when and how to append their standard.
> >     >
> >     > This seems fully compatible with your words below, so I see that we
> are in fact in agreement. Do I miss something?
> >     >
> >     > Pascal
> >     >
> >     >> -----Original Message-----
> >     >> From: Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jmh@joelhalpern.com>>
> >     >> Sent: vendredi 25 mars 2022 12:02
> >     >> To: 'Toerless Eckert' <tte@cs.fau.de <mailto:tte@cs.fau.de>>; Pascal
> Thubert (pthubert)
> >     >> <pthubert@cisco.com <mailto:pthubert@cisco.com>>
> >     >> Cc: wgchairs@ietf.org <mailto:wgchairs@ietf.org>; rfc-interest@rfc-
> editor.org <mailto:rfc-interest@rfc-editor.org>
> >     >> Subject: Re: 3rd party SDO cross-referencing of IETF work (was: Re:
> >     >> Chair/datatracker tracking expired WG documents ?)
> >     >>
> >     >> You have missed the big problem.
> >     >>
> >     >> There is a reason that having external standards normatively
> reference I-Ds
> >     >> is difficult / problematic.  (And I hav edone it even though it is
> against
> >     >> the rules.) There may well be significant, even incompatible changes
> between
> >     >> even a late stage I-D and an RFC.  An external reference relying on
> the I-D
> >     >> would be incorrect.  And it is not enough to just say "well
> they should write
> >     >> it so as to reference whatever the I-D becomes, since they would
> need to look
> >     >> at the changes to see if they were wanted.
> >     >>
> >     >> Yours,
> >     >> Joel
> >     >>
> >     >> On 3/25/2022 6:48 AM, 'Toerless Eckert' wrote:
> >     >>> Added rfc-interest. Not sure this is ideal set of lists, but
> hopefully
> >     >>> better
> >     >>>
> >     >>> I think i have a proposal that would not only solve (i hope) what
> >     >>> Pascal is concerned about, but would also be (IMHO) very useful
> for the RFC
> >     >> series:
> >     >>>
> >     >>> How about we do crearte on datatracker a mechanism to officially
> >     >>> register a third-party reference to a particular IETF document.
> Draft or
> >     >> RFC.
> >     >>>
> >     >>> Everybody who writes an external document could create such a
> third-party
> >     >> reference.
> >     >>> We'd have to discuss access control if its abused.
> >     >>>
> >     >>> The one benefit (which i was interested in) would be that we would
> >     >>> finally start getting some inight if/where our documents are being
> >     >>> used elsewhere in the industry. Especially given how a lot of
> industry
> >     >>> bodies  work with closed documents, it is completely impossible to
> >     >>> just scrape the Internet to find uses (as its "kinda" done in the
> >     >>> research world). Especially now that we're trying to reach out to
> more
> >     >>> external SDO in IoT, Media operations or other industrial
> verticals,
> >     >> something like this would hopefully be timely.
> >     >>>
> >     >>> The other benefit would be that whoever creates the reference would
> >     >>> (automatically) get status updates about the document. So the
> foreign
> >     >>> SDO document editor or manager could use this to track the IETF
> reference
> >     >> and status.
> >     >>>
> >     >>> Depending on what we put into such "foreign reference" (to be
> filled
> >     >>> out when it's created/updated), we would likely be able to satisfy
> more
> >     >> work-flows.
> >     >>>
> >     >>> Cheers
> >     >>>       Toerless
> >     >>>
> >     >>> On Fri, Mar 25, 2022 at 10:28:20AM +0000, Pascal Thubert (pthubert)
> wrote:
> >     >>>> Along the same line (though a different problem that we'd need
> to fork as
> >     >> a separate thread) is our wording for IETF references.
> >     >>>> At the moment we indicate that external specs (think say IEEE)
> must not
> >     >> reference drafts. But when the draft stalls before RFC, this makes
> the
> >     >> reference completely unusable. Makes no sense to me, and hardly
> reflected in
> >     >> practice. A better practice would be how we eat our own dogfood,
> which is
> >     >> that a draft must not be a normative reference when standard X is
> published,
> >     >> whether by IETF or else.
> >     >>>>
> >     >>>> Interested in following that up too? If so please fork.
> >     >>>>
> >     >>>> Note: this can effectively hurt. Within the last year or 2, I
> faced that
> >     >> issue with both IEEE and ETSI. At ETSI it was mostly theoretical
> and we kinda
> >     >> forced our way to reference I-drafts arguing that the doc we are
> writing is
> >     >> not a standard. OTOH, at IEEE that was harder. We had text in
> 802.11md about
> >     >> the proxy ARP function and the fact that there's also IPv6 to care
> about.
> >     >> Incidentally, the text cited a draft in progress for the proxy ND
> operation
> >     >> (now RFC 8929) as an informational reference (all non-IEEE
> references are
> >     >> informational). At the last minute, the whole change was removed
> from .11md
> >     >> on the grounds that the I-D reference was not RFC, and the text was
> frozen
> >     >> for publication. At that time, the I-draft had been waiting for its
> turn in
> >     >> the RFC Editor queue for months. The RFC was pulled from the RFC
> editor queue
> >     >> and published within weeks after the freeze. I discovered the .11
> removal
> >     >> only later, appealed, but the freeze is immutable.
> >     >>>>
> >     >>>> Keep safe;
> >     >>>>
> >     >>>> Pascal
> >     >>>>
> >     >>>>> -----Original Message-----
> >     >>>>> From: WGChairs <wgchairs-bounces@ietf.org <mailto:wgchairs-
> bounces@ietf.org>> On Behalf Of Henk
> >     >>>>> Birkholz
> >     >>>>> Sent: vendredi 25 mars 2022 10:40
> >     >>>>> To: Valery Smyslov <valery@smyslov.net
> <mailto:valery@smyslov.net>>; 'Toerless Eckert'
> >     >>>>> <tte@cs.fau.de <mailto:tte@cs.fau.de>>; 'Tools Team Discussion'
> <tools-discuss@ietf.org <mailto:tools-discuss@ietf.org>>;
> >     >>>>> wgchairs@ietf.org <mailto:wgchairs@ietf.org>
> >     >>>>> Subject: Re: Chair/datatracker tracking expired WG documents ?
> >     >>>>>
> >     >>>>> Coincidentally, I was expressing the expressing the exact same
> >     >>>>> sentiment in a side-discussion two days ago. I'd really
> appreciate
> >     >>>>> that feature, both as a chair and a contributor.
> >     >>>>>
> >     >>>>> On 25.03.22 09:04, Valery Smyslov wrote:
> >     >>>>>> Hi,
> >     >>>>>>
> >     >>>>>>> Is there a way for datatracker on a WG's page to
> (automatically)
> >     >>>>>>> show
> >     >>>>> expired WG documents ?
> >     >>>>>>>
> >     >>>>>>> I have one such draft in my WG and it wouldn't show up on the
> WG
> >     >>>>> page.
> >     >>>>>>> Of course, in general one may not want to bother about expired
> >     >>>>>>> drafts unless explicitly added, but for WG document IMHO, it
> would
> >     >>>>>>> be great if they would automatically show up in in the WG
> section
> >     >>>>>>> unless their status is maybe accordingly updated or the like
> >     >>>>>>
> >     >>>>>> I also think this feature would be useful, because now the
> expired
> >     >>>>>> WG document is not shown at all at the WG page and it's
> sometimes
> >     >>>>>> difficult to find it (you need to remember the name).
> >     >>>>>>
> >     >>>>>> Regards,
> >     >>>>>> Valery.
> >     >>>>>>
> >     >>>>>>> Thanks
> >     >>>>>>>        Toerless
> >     >>>>>>
> >     >>>>>>
> >     >>>>
> >     >>>
> >
> >     _______________________________________________
> >     rfc-interest mailing list
> >     rfc-interest@rfc-editor.org <mailto:rfc-interest@rfc-editor.org>
> >     https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>
> >
> >
> > _______________________________________________
> > rfc-interest mailing list
> > rfc-interest@rfc-editor.org
> > https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> >