Re: [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)
Eric Rescorla <ekr@rtfm.com> Fri, 25 March 2022 17:24 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 A1FDB3A17BA
for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Fri, 25 Mar 2022 10:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
t=1648229054; bh=S7GG+b/mmDMU09cHqTQQ6RvzmKfVFek4V8qiGhsT77M=;
h=References:In-Reply-To:From:Date:To:Subject:List-Id:
List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
Cc;
b=QWeI7XH4pNd2wD9et32YEp9Msu7jXNV5BTgwE0aRriIrFRZi9r90kTFkvXcMnpkOp
28RyveJ/FY6pntais/JUzT/cQKTdQ08FmjafPbzjbcNdERhXYei642XHXuibkkVBNA
TZOHs/N25aMrFOVOH822SwBdDXFCupghZjzmSIko=
X-Mailbox-Line: From rfc-interest-bounces@rfc-editor.org Fri Mar 25 10:24:07 2022
Received: from ietfa.amsl.com (localhost [IPv6:::1])
by ietfa.amsl.com (Postfix) with ESMTP id AF97D3A1762;
Fri, 25 Mar 2022 10:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
t=1648229038; bh=S7GG+b/mmDMU09cHqTQQ6RvzmKfVFek4V8qiGhsT77M=;
h=References:In-Reply-To:From:Date:To:Subject:List-Id:
List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
Cc;
b=sef8K2iUW7pE/KbgtNHFajHvOKL/1YnBot1FfvschN+MNdTmQG7+GErsYS1D9tIvi
NgvYVe/C7X22+HQFrU6xpRvdue/QmPr+Wow2ac+fk5nJY7NgrQ08SjBQrW89SHoHfN
4+hXKqlYzs5VxV508lz3XEq6RnCK/oox7PZhtCBM=
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 685E33A0C26
for <rfc-interest@ietfa.amsl.com>; Fri, 25 Mar 2022 10:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_NONE=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 (2048-bit key)
header.d=rtfm-com.20210112.gappssmtp.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 ByLxfZH7qx2S for <rfc-interest@ietfa.amsl.com>;
Fri, 25 Mar 2022 10:23:53 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31])
(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id E4CB53A095D
for <rfc-interest@ietfa.amsl.com>; Fri, 25 Mar 2022 10:23:53 -0700 (PDT)
Received: by rfc-editor.org (Postfix)
id CE85222B3C8; Fri, 25 Mar 2022 10:23:53 -0700 (PDT)
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1])
by rfc-editor.org (Postfix) with ESMTP id CDA56162FEA
for <rfc-interest@rfc-editor.org>; Fri, 25 Mar 2022 10:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=rtfm-com.20210112.gappssmtp.com
Received: from rfc-editor.org ([127.0.0.1])
by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id RtwiYYaRyn2c for <rfc-interest@rfc-editor.org>;
Fri, 25 Mar 2022 10:23:50 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com
[IPv6:2607:f8b0:4864:20::12d])
by rfc-editor.org (Postfix) with ESMTPS id 045F53BAA5
for <rfc-interest@rfc-editor.org>; Fri, 25 Mar 2022 10:23:49 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id e9so5635247ilu.9
for <rfc-interest@rfc-editor.org>; Fri, 25 Mar 2022 10:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=rtfm-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=93NDnSRjet7s/sEvVSeSXLJu56Gl0qvTl4IpiCK8cRo=;
b=XhsUMXYFM8cIlx53TraL1QB25S8TOI2AJqlsssxyNd6otrnnj/+CeCmwIFufwYfOQ4
4Uh66R0cXViF7WwxRyiGrbo+cUOoFQ/FhPF+0UILq/F+vIinYoTp7j/pPdGacNZ9mTFz
Nt3lSpCxJRPl36ahBT/7JZiyx9Eia28grKnMkHukPURdcitc1c2m1xeSCrycST/0xrev
R2CvKSBDwJDTJ7JHk3PYcB6EgL7/vIJFSVkfLgnUe/jGmBxVebxtEfGOnRBiqHglLkpb
RVdI2/7A/Nsxjbm9jtrIawKFsueua8JiC42y+37v33UPoDE5VOlgPCh4fXjr5v9IJG7a
S+pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=93NDnSRjet7s/sEvVSeSXLJu56Gl0qvTl4IpiCK8cRo=;
b=aHifgtBBwbs9B/GjB1Ck4zzAaLz0m/iTqMmMbWDI16FLcKBbyCa9OqtD8qBjqLu9Il
wU+N2esusnQIZCR28wqoecgJQ9Wj9sEjQLw27CkcEeCh+dAVKRJ2hsKRjwNmV5Uz5QyH
kn92AvYqdPGAWxTI4NvVB93E8lsi9eEhy4OH1A4SES2+37j/6l6aFv6e2k44ojli059x
0YwSPhQcxb2Pr538Qn3Kgro8gl9gaK0HO3npVMxVm+6P7w4CrqVOpuKtsa569ynWy7jm
pPGA/4nYCZBK7uo9ZuSYFPW6CwB7NtARlmNFR6tR6faWnVrnKVFO8/r16Q+46bqay4pO
QJwQ==
X-Gm-Message-State: AOAM533+EpiHPnTs7IzcpihoDFFpGCvAnO6ig9IRD9rL/kqU1VQw3IC4
h2C5pFVqTYgvOC38VoJQj7mwUonm07q0AkQWJ9tr+w==
X-Google-Smtp-Source: ABdhPJzyzpA7ySFwx72U9+3RAlTmrQTA5+ipKMrJ1d70sUp7X7nrwBhGJyaLzZqciq8m2YI0V4lu1dO5GJcWJyNp2js=
X-Received: by 2002:a05:6e02:1708:b0:2c8:2f44:fab7 with SMTP id
u8-20020a056e02170800b002c82f44fab7mr5673525ill.10.1648229028883; Fri, 25 Mar
2022 10:23:48 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <95b5dab0-3eb5-536d-85fc-d428f26364ed@joelhalpern.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 25 Mar 2022 10:23:12 -0700
Message-ID: <CABcZeBOSMRffY6cXjwn7A6d=JWDJmmBrgHxiPD-XRMTMazOjLw@mail.gmail.com>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/7n4RBk_CdZrtbexwBtOY0R7T1Is>
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>,
"Pascal Thubert \(pthubert\)" <pthubert@cisco.com>,
"rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>
Content-Type: multipart/mixed; boundary="===============7425853456724403015=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: "rfc-interest" <rfc-interest-bounces@rfc-editor.org>
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> 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> > >> Sent: vendredi 25 mars 2022 12:02 > >> To: 'Toerless Eckert' <tte@cs.fau.de>de>; Pascal Thubert (pthubert) > >> <pthubert@cisco.com> > >> Cc: wgchairs@ietf.org; 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> On Behalf Of Henk > >>>>> Birkholz > >>>>> Sent: vendredi 25 mars 2022 10:40 > >>>>> To: Valery Smyslov <valery@smyslov.net>et>; 'Toerless Eckert' > >>>>> <tte@cs.fau.de>de>; 'Tools Team Discussion' <tools-discuss@ietf.org>rg>; > >>>>> 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 > 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
- [rfc-i] ****SPAM**** 3rd party SDO cross-referenc… 'Toerless Eckert'
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Joel M. Halpern
- [rfc-i] ****SPAM**** Re: 3rd party SDO cross-refe… 'Toerless Eckert'
- Re: [rfc-i] ****SPAM**** Re: 3rd party SDO cross-… Salz, Rich
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Joel Halpern Direct
- [rfc-i] ****SPAM**** Re: Re: 3rd party SDO cross-… 'Toerless Eckert'
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Pascal Thubert (pthubert)
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Eric Rescorla
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Brian E Carpenter
- Re: [rfc-i] [irsg] Re: 3rd party SDO cross-refere… Melinda Shore
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… BRUNGARD, DEBORAH A
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Keith Drage
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Pascal Thubert (pthubert)
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Brian E Carpenter
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… BRUNGARD, DEBORAH A
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Salz, Rich
- [rfc-i] Tao [3rd party SDO cross-referencing of I… Brian E Carpenter
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Joel M. Halpern
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Robert Sparks
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Joel M. Halpern
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Brian E Carpenter
- [rfc-i] Normatively referencing I-Ds. (Re: 3rd pa… Carsten Bormann
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Salz, Rich
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Salz, Rich
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Joel M. Halpern
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Pascal Thubert (pthubert)
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Salz, Rich
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Tim Wicinski
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Joel M. Halpern
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Salz, Rich
- Re: [rfc-i] Normatively referencing I-Ds. (Re: 3r… Brian E Carpenter
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Brian E Carpenter
- Re: [rfc-i] Tao [3rd party SDO cross-referencing … Salz, Rich
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Pascal Thubert (pthubert)
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Pascal Thubert (pthubert)
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Pascal Thubert (pthubert)
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Salz, Rich
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Brian E Carpenter
- Re: [rfc-i] 3rd party SDO cross-referencing of IE… Pascal Thubert (pthubert)