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

"BRUNGARD, DEBORAH A" <db3546@att.com> Tue, 29 March 2022 20:27 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D153A1C64 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Tue, 29 Mar 2022 13:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1648585674; bh=3e2lFzUxC2rG0Jdm79LvImOCgdb39bs2G1GHySosdf4=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=EiYx2uDY1U6QCuNXTyn5jG52zotcRoE3qU0gTrZkUGDG3FS3tAw/LBHH/q2AEppRa LCs97jPsSQsuuyn9RzOzvcYTmpqyU0QcMpHibk/41m/kkYAgd0k34sBOvSIvAP2oUK Op9WX9ffjfk6DCF3DFEnVunIY1wDklDmTf7O109M=
X-Mailbox-Line: From rfc-interest-bounces@rfc-editor.org Tue Mar 29 13:27:49 2022
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C81153A1BEA; Tue, 29 Mar 2022 13:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1648585668; bh=3e2lFzUxC2rG0Jdm79LvImOCgdb39bs2G1GHySosdf4=; h=From:To:Date:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Qw37ujXGTo7qDzY86wJ95MBGmBuMsvKMp8CZhUyX06vvgpM4a6cIcDYqa3bitJKLB KeJ4TcR37RPRRJF0Awuolfdxz57sH+0z/LyvOt0VgoDimePXrlBQ0mvRf4kcAM+P5J ItzZyDB8mVM+1nQrKvmMxt8A6EUFmxcoltUkcTkk=
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308AC3A1C19 for <rfc-interest@ietfa.amsl.com>; Tue, 29 Mar 2022 13:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 yggGmRupSPB4 for <rfc-interest@ietfa.amsl.com>; Tue, 29 Mar 2022 13:27:33 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 8E59A3A1BD1 for <rfc-interest@rfc-editor.org>; Tue, 29 Mar 2022 13:27:33 -0700 (PDT)
Received: from pps.filterd (m0288871.ppops.net [127.0.0.1]) by m0288871.ppops.net-00191d01. (8.17.1.5/8.17.1.5) with ESMTP id 22TIJnf7027785; Tue, 29 Mar 2022 16:27:25 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0288871.ppops.net-00191d01. (PPS) with ESMTPS id 3f479y4qjb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Mar 2022 16:27:24 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 22TKRNI0032645; Tue, 29 Mar 2022 16:27:23 -0400
Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 22TKRHmi032526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Mar 2022 16:27:17 -0400
Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id 45F954014C33; Tue, 29 Mar 2022 20:27:17 +0000 (GMT)
Received: from MISOUT7MSGEX2CB.ITServices.sbc.com (unknown [135.66.184.206]) by zlp27130.vci.att.com (Service) with ESMTP id 11A63400B577; Tue, 29 Mar 2022 20:27:17 +0000 (GMT)
Received: from MISOUT7MSGEX2DA.ITServices.sbc.com (135.66.184.178) by MISOUT7MSGEX2CB.ITServices.sbc.com (135.66.184.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 29 Mar 2022 16:27:04 -0400
Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGEX2DA.ITServices.sbc.com (135.66.184.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24 via Frontend Transport; Tue, 29 Mar 2022 16:27:04 -0400
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.46) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Tue, 29 Mar 2022 16:27:04 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uag1juYHxwpS0MlhIFeAAjo7eg8s5kzpA6t+v7KvUP1T/Sq9kzmtRcQFmSEWeybkYiB1IUaQhrbs2RFTUwMC0rGKlEFNalTsKInP+SWq8RzIWc9n3g+s5y2BvoxSZT8z1uOV96Rc3hgcmBsJkD3DUEKJ5Kk/jCa05F5Ru52P2ax9A5+IOiazTHH2MlixnjbCEQV/mP/DalmFGCdvy5elIRvGVT1VBQLmjF2dhkWcggg4Ac6vVZY5G5u/GeWTTV64Mi7lCRxEep0g1dovOu0ETWJllIi7fFk8yFRykqfbrP6Tg+DO48HwfYcYWh+/WwWzQNC7s2+cKYck0fW1zeN3Ig==
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=jQN/kGxFdgb5E48rZ/KaCVs+xjQ3ZxJPjt20vyCwi0Y=; b=Ok8Z5pmMXOt4XjE08CpCsAmGxHDaNFzA4JSvj4CHa+xZEVfrfUf855ymWm85yIORceAeHbIndHLXBUlP8uM6d4zTW/4tBpbNaqntWBi821YjlC2Y83lPrNSMEX47Bcz5pzNaXMSV9j35SGj2WXSO09yPGUoegZ0eKWADMIrLAyclupvG/Wz5bkQfD2sw3kspm8UdjhuiG82zvsU9SD+PKAOc24aO1ro696pQw7A4WqleEH0TB9PyrMhRsFV7XXjRy5PJOyz1OJNbRhUHfGx3S9wEFJxnbV0ws1Zh7fGfdsrjh14NpxKgR78at7YNefzszbOBad/AGN+dNaltvaDCKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jQN/kGxFdgb5E48rZ/KaCVs+xjQ3ZxJPjt20vyCwi0Y=; b=xSuY9QfGbKFgJ6i3CVCfYcmd1EtjJezBPDijXTSpd+8mdSFCQ7trPUeKUJ/a8jBKI1Nu+37TCz85ZuWg0bWG0S8LwDJ+Y5Uu5GczLZAChwxSGozVOyRynAqHEXF4H7AE5MGE/3lZgJVFInM6FlVfwVa7U99ZyfgsOwzEuy0Ek3w=
Received: from CH0PR02MB8291.namprd02.prod.outlook.com (2603:10b6:610:fb::5) by SJ0PR02MB8643.namprd02.prod.outlook.com (2603:10b6:a03:3fd::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.17; Tue, 29 Mar 2022 20:27:02 +0000
Received: from CH0PR02MB8291.namprd02.prod.outlook.com ([fe80::ecae:4955:5b5d:3ede]) by CH0PR02MB8291.namprd02.prod.outlook.com ([fe80::ecae:4955:5b5d:3ede%6]) with mapi id 15.20.5102.023; Tue, 29 Mar 2022 20:27:02 +0000
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Eric Rescorla <ekr@rtfm.com>, "Joel Halpern Direct" <jmh.direct@joelhalpern.com>
Thread-Topic: [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)
Thread-Index: AQHYQDXk21tLnFvDH0+L3QPUzJn3xKzP7w8AgAAgCgCAAAypgIAAPdQAgAPxSACAAQjggIABc9qA
Date: Tue, 29 Mar 2022 20:27:02 +0000
Message-ID: <CH0PR02MB8291A7A9598871412C035882D61E9@CH0PR02MB8291.namprd02.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: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9208fe5b-488e-4bd9-b9a5-08da11c27bd6
x-ms-traffictypediagnostic: SJ0PR02MB8643:EE_
x-microsoft-antispam-prvs: <SJ0PR02MB86431973A6597CF68DF4EDCDD61E9@SJ0PR02MB8643.namprd02.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: KLXM3AA8smCwi/YCyLbgBoUd/6jDtDyGJEWLV0fMrRoicylVENlC+t8u64X4XzbgS+VACMuqrticgKAScEfSQtGzAJltPDn3uDuPDZ+2ytd75ThoNZzyyx3to7lA/fpi67n+9HP8oisXxcQlkdyTr31iiFS6btuBxOA7NstUGetiKBG0jOwVhNNpvezBRFxYhP18tnFyoHVtVK7PW92XegQFmrSxTeZ6jiFs8cwmxxM7owjqTTnSQdAc0pZ2v2OWJjb6vVbbYFf4hJXJiI+o12+N3I/GZDRJMpfETdiii14je3ocGgGh4jzmdMfIFCaqsgJrGBMka3d53Nje0Y/CdSwKPe6DsM+M9V3giCggX16DqXs/wSX7qwUFpLh6YiDtxAF5XthF8KDIApmBtHNcFtRlymBIiMskKlrAbbmICH6/XJb0RifiIcB9FiPoVqTES64ZzjOBoj3AmsmIhWbF6TnhryUzzXIhHOjWqwlddQpy9mFvKfKiTfJv4pIUS+xbmvFWhS1F5iJamNw8X9zky790Gk2c3DGIfd/k6Zd+ha+TVrtmsMfeF1S0YqR1+rYJBKyHDurzEMNAlbkYR46kWyJq6xKR7RWyXBP6rpp59J6cor9snddc0ek/b7PLMAoVm91zEJWHDva3SJydibP/CTb5KphKbDBVoYM1hB7EpFezXfT/Bve7YnjVYYgCYJG7INRzzsQjrWbMUiMlv4axlU1N0SsPPi5iuJbJ5jSypxQbigiFGn3gtrVgT//VhzVJZEiwMqCD4Ra0zGTO5vtbaQXlhLkYqwroTJbzw90kF5oQVoVj0Gtdyxyh/rtyFJPxCyyVzAz2XvZWttwFjmxym9rYqZ2NB7A830eg7ylXN+g=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR02MB8291.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(26005)(966005)(83380400001)(86362001)(76116006)(5660300002)(71200400001)(66946007)(186003)(508600001)(7696005)(54906003)(122000001)(6506007)(2906002)(8936002)(8676002)(55016003)(38100700002)(82202003)(66574015)(9686003)(53546011)(52536014)(316002)(38070700005)(30864003)(33656002)(64756008)(66446008)(66476007)(66556008)(82960400001)(4326008)(110136005)(498844002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cSt3MTBNU1c2c0NZWDcweXlGYVdIdWZtNWIwcDNWNmJJaFhhNGNlaW9EY2dw?= =?utf-8?B?ZnB2TWJZTWpoZ0wrNjdsUkxnMXlpb1AvZmZyYVEwQVh6R3pmelEvcmpkVlVj?= =?utf-8?B?ZmlZbVZZMWszd2xselB6b1R6ZW10VjJtMUZBR3IrMlJ4SGd6aGNzZCtWQ3d3?= =?utf-8?B?eDIwR3ZsTWExU3lYbEROZFJmLy93UC9qVmZpM1RMSEJtYzdGK2Zvc0pPa3h6?= =?utf-8?B?dFdiTXlrNlNsM3U5WXVoUUs0QlJaZjJWMUdiajFLQWtoYm5GOWwrQ3RXWEdS?= =?utf-8?B?bjdIL3lZWjJ2ekMzbU90VTJ3ZTk1K0dxTTE1Q0NzL0ZuREF2cjZ3alhqc3h3?= =?utf-8?B?VzdSRUtYRXVLYmlmK1pUakNCTUs1WitONHphWkVzWC9qdlFMdmdUQ0o0anBZ?= =?utf-8?B?M1kvd2UwVTllWU5URVJ0U1VPemZCRTV5djJUSys3aGU5OUN3Q1V0SFpDd2pn?= =?utf-8?B?RUdld0hNVGVtK2d5VEFPaHduTWVORkdETHFianBNemZjTk9SUndXL1h2T3ZD?= =?utf-8?B?TkIyUlZvYktNK0dsUEhwbklmVk52blVlRmtLSnZWVGRVV0pMUVVrZFA3em1u?= =?utf-8?B?dThxY2ovb2dQcXJYM3dQcXEyWHE5d2xNbE1XUytHNkYvN2xkdk9hRWVibW5k?= =?utf-8?B?VXdYeTVXK3VNRmpwTE95WDZyR2hlMklJMzIvN0pDVFNyd0VmWTl1bGN5T21V?= =?utf-8?B?anhwU1FKVktaUjd5ZWZOa3c5bWhNOWRCZmdxNDZ6TGNNbHN0alo1U0xWVklC?= =?utf-8?B?QnNCUVJqS3E4Y2EyWmU3SnlFYUF2UHU1MkdvVk81WElESThHMTNVTHNlZElE?= =?utf-8?B?ZDg3UlVFaUpiWkpoZ3pyanQzN2dObkc2YmpMUHFlSlZKZDZRdWVnaDRiQUZq?= =?utf-8?B?VzdiUUI4ay9RRjNQWDVqQ3QxNTZNaEluSkJVWEh6dDhpNExtbFNYRnpHbnph?= =?utf-8?B?UEJMekg5SlBwa2ZhVWJNRlN3SjYxeXJZdDdXS3JKTmtkSlVEcFVIcXBNMGt1?= =?utf-8?B?cnlkOFU4aFZYNkdsRS92TG5xWUJCZXgrWXRESENjTjJNdjlRUi9Uc1poVUx6?= =?utf-8?B?dW11TjhlMzhKNHNyTDJyTVd6aHlUNE1JMTRGOVJjbkd2Rmg2ejZhYnQ5RUhN?= =?utf-8?B?V2VQZlMrck14R2RJVWNvaU4vdWI2aU5WaWt3WEZ1eDdMT3FyYkw1RnU0MFdW?= =?utf-8?B?Q2k0dGYySE4wUEg1RXRTQ2RSbWV3bGg0Y055aU9nRHpDalpDY3BDa0dxRjN3?= =?utf-8?B?THFqUEJ2Z2lsUnlnUDR3VXVhT0duamgrN2JlenJTTWZNSitJL01XTTJpMXFJ?= =?utf-8?B?cGd1SmV5ZSt3WE5CSFlNYWVYSGV4bjVXQlRPLzlySzllTGFKTjUzQ2NiM21X?= =?utf-8?B?Z0tia2UzeFVYQlN5SjZ1aTgwU0FrQTlkWUc4ODdaN1UzQy90RktyVWpDMjBJ?= =?utf-8?B?T3AwaDJxMEx0WTlPNHF2QnZsYzBDMnR1ZjdSL3ZQQ3ROVjNUVUlETmhJOFc4?= =?utf-8?B?aFFVRnA2SmFXK3dsYVA5VkRxSVpxcDVVSTFXQ3pxS0k3aXFjdndVQjljK01y?= =?utf-8?B?cFovT2NBSTFvMktVQkpvdmpFeldTZGlQUm5DNi82aW44dDFzelhaRE96Q2RI?= =?utf-8?B?NlNzVEFZNzlPcVBzdTFmVFQrRUlyZzlLSmlFMXFEbjZYdlVMQ3pzd2htT2RO?= =?utf-8?B?THUyWU5RaW5UM1FkU1gySlUvL1JxbkdQSmkzeHRPOSt3aVBnWTBQYzNTaHRV?= =?utf-8?B?dk03dHJRWEJCZ0RDbGpUNlZubkU4NDhzUy94eldDZk9aRmlrVS9lT043Mit0?= =?utf-8?B?MzZwZGI1Y21YSTVScjA1NTM3UnJIQVBoUGU2cDlteTJlc21OWUYrVEx6T0cr?= =?utf-8?B?UzI4L2lDbEF5SFlpcExuUEpjSHZ0WHhkR1h4Q3VTU3NWbkF0cHpQTUtuSWRh?= =?utf-8?B?dWdCOW1LTmFZMFkyVXFObHh0YWpUWGFoTEwyV1gxdjI2ekdJQnJoQ3Rlb0tK?= =?utf-8?B?OHBMbTA1ZzhBdE9jdlVOTzRkZkM1YVJHL2VDWm5qWG9GQlpoZmFya2xHWGdV?= =?utf-8?B?K3czVloyUTV3UmgwdEdhVG55OVRONFpxdUVNaXM2NStJeXBGZlJwTkZaWXVH?= =?utf-8?B?amt4SXQ0UjUzbm1nL3Y2Z3R2Y0hwaWU2QWExQ0M0d0xDS2x5bWt2QXZqK0hs?= =?utf-8?B?TjFmWCtJNFhhcCtySngrWEltWnpla1ZxZlFsYUlxWDZWL0VpMXh3dm92dnhG?= =?utf-8?B?Rld0L3FiZENKb3gwN09GckdodlRScnBxYlpmK2xhOWlNZ1JDNVdzdzZ4aExC?= =?utf-8?Q?OHMpspgROK6vgW3t4R?=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR02MB8291.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9208fe5b-488e-4bd9-b9a5-08da11c27bd6
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2022 20:27:02.4250 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9g9aD9KzjdBIOug4kvs3LPr0PhXzLUXrCJsStO723d7Bt6MXHdW2RWm3yRZwKDLg
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR02MB8643
X-TM-SNTS-SMTP: BA796C027B33C8AD7779CF5FF27A16E69041FE40E488651C33D3590290B64C262
X-Proofpoint-GUID: rnbF7U8zT5YfZWHeEB3JeW8oy3uYmZS8
X-Proofpoint-ORIG-GUID: rnbF7U8zT5YfZWHeEB3JeW8oy3uYmZS8
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-29_08,2022-03-29_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 spamscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 impostorscore=0 mlxscore=0 adultscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203290110
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/ZOL1zAhQ_zwADK9zq53UeCB4BMI>
Subject: Re: [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Cc: "wgchairs@ietf.org" <wgchairs@ietf.org>, "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: "rfc-interest" <rfc-interest-bounces@rfc-editor.org>

Hi Pascal,

These couple of sentences in the Tao are actually from RFC2026 and about the transient state of I-Ds.

As Brian explains, we do allow normative references in a PS document, they just need to wait before publishing (the famous MISSREF state). If under Informative, listed as "in progress". The "Note" in section 2.2/RFC2026 explains. One of my most saddest cases (595 days and counting) has both examples:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

As for convincing other SDOs, usually they have a high level group making these decisions. The group making the rules knows about the maturity status, copyright, IPR, etc. It is not done at a working level. ITU is always waiting for us to give the go-ahead for RFC status and we even have a way to fast-forward in the publication process to get an RFC number. On your example, probably IEEE does not allow references to drafts, they didn't want to wait, and they thought their document was ok without the reference. Was the IETF-IEEE coordination group aware?

Maybe you want to do an update to RFC2026 to clarify, not sure it will change another SDO's process. I'm not sure myself what I would agree with to change, as Brian says, it needs to be clearly marked "work in progress", and that's already there in the Note.

If want, mail the liaison-coordination list as I'm sure the liaisons know what each of their groups allow-

Deborah


-----Original Message-----
From: WGChairs <wgchairs-bounces@ietf.org> On Behalf Of Brian E Carpenter
Sent: Monday, March 28, 2022 5:24 PM
To: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; Eric Rescorla <ekr@rtfm.com>om>; 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://urldefense.com/v3/__https://www.ietf.org/tao.html__;!!BhdT!nMd2ztC3cgksqshpIlBhKt2GgDXPW6R1_4S-Lsq_rcz7mHODSz1JMhrHDY79R2bHZa3tMurDJrLYRwm5HnpHFdG-Fg$ . 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>om>; 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://urldefense.com/v3/__https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest__;!!BhdT!nMd2ztC3cgksqshpIlBhKt2GgDXPW6R1_4S-Lsq_rcz7mHODSz1JMhrHDY79R2bHZa3tMurDJrLYRwm5Hnpw6e1-9Q$  <https://urldefense.com/v3/__https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest__;!!BhdT!nMd2ztC3cgksqshpIlBhKt2GgDXPW6R1_4S-Lsq_rcz7mHODSz1JMhrHDY79R2bHZa3tMurDJrLYRwm5Hnpw6e1-9Q$ >
> 
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://urldefense.com/v3/__https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest__;!!BhdT!nMd2ztC3cgksqshpIlBhKt2GgDXPW6R1_4S-Lsq_rcz7mHODSz1JMhrHDY79R2bHZa3tMurDJrLYRwm5Hnpw6e1-9Q$ 
> 

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest