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

'Toerless Eckert' <tte@cs.fau.de> Fri, 25 March 2022 12:06 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 29F373A1216 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Fri, 25 Mar 2022 05:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1648209972; bh=hiKK+ehRPSi8ZwOC0U+HflhvMyjx8sAaL4RixwFd8rQ=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=Rop5xFznzaxXu6fAT+N8016bgYQLd0A6kbjoe7VEKkDHxWib5D4jiCO7r4rzs/Rca I82LNbrFIAC2hrEvRNoqHvER2Mb6S4USAxOXvQqk6PrHCIc60pW0Q29TGMW3kOI74i G6gkdZcEDwdxdoHMxAQecPJXz5pQWlvvEy1wUry0=
X-Mailbox-Line: From rfc-interest-bounces@rfc-editor.org Fri Mar 25 05:06:10 2022
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7423A11C3; Fri, 25 Mar 2022 05:06:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1648209970; bh=hiKK+ehRPSi8ZwOC0U+HflhvMyjx8sAaL4RixwFd8rQ=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=ypiteNRSEVc+3Is8YX92qA1AfjPZQFN+F8kncd0iNSv6zMTlGpYFOnYn9uHVaRGgT gjwaS+rvjRs24qdv09BfYI13vznTGfqvtJIQWaqFkhbuJ7zdUACtXZP2RR5GxcY9Ju ib5JCJZ4t3XLLgWqpI40ThhhxmprpObwtmQ+rcLY=
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 8108E3A11C3 for <rfc-interest@ietfa.amsl.com>; Fri, 25 Mar 2022 05:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.881
X-Spam-Level:
X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 wuKy64KgqpMb for <rfc-interest@ietfa.amsl.com>; Fri, 25 Mar 2022 05:06:02 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BFD3A11C4 for <rfc-interest@ietfa.amsl.com>; Fri, 25 Mar 2022 05:06:02 -0700 (PDT)
Received: by rfc-editor.org (Postfix) id 0615E3BAA5; Fri, 25 Mar 2022 05:06:02 -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 0329B15EE85 for <rfc-interest@rfc-editor.org>; Fri, 25 Mar 2022 05:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
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 Xbu8buvSlWFT for <rfc-interest@rfc-editor.org>; Fri, 25 Mar 2022 05:06:00 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) by rfc-editor.org (Postfix) with ESMTPS id C4BC43BAA5 for <rfc-interest@rfc-editor.org>; Fri, 25 Mar 2022 05:05:59 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id D7F6E58C4B0; Fri, 25 Mar 2022 13:05:55 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 295594EAA04; Fri, 25 Mar 2022 13:05:55 +0100 (CET)
Date: Fri, 25 Mar 2022 13:05:55 +0100
From: 'Toerless Eckert' <tte@cs.fau.de>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <Yj2wI/nc+gzbIBMF@faui48e.informatik.uni-erlangen.de>
References: <Yj2d4DJMFWJOxoZa@faui48e.informatik.uni-erlangen.de> <317196df-3363-36c9-2421-02d9e229f664@joelhalpern.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <317196df-3363-36c9-2421-02d9e229f664@joelhalpern.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/xPobHvypMxGZmJusO66fIzdh1nM>
Subject: [rfc-i] ****SPAM**** Re: 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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: "rfc-interest" <rfc-interest-bounces@rfc-editor.org>

I am not proposing to change this recommendation (don't reference drafts).
All i am saying is that we should have official tracking, of when external
SDO are planning to reference such a TBD RFC (and also final RFC). In case
it is a draft/TBD-RFC, the WG chair for example would know which external
SDO are waiting for it and could accordingly take support the communications
with that SDO, or even leverage the information about such dependency for
priorization/communications in the IETF.

But of course, if an external SDO does choose to ignore our recommendation
and is actually referrring to a draft in a published spec, then i still would
rather like to know about it via such an explicit tracking mechanism than
not to know about it.

Cheers
    Toerless

On Fri, Mar 25, 2022 at 07:01:56AM -0400, Joel M. Halpern wrote:
> 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
> > > > > 
> > > > > 
> > > 
> > 

-- 
---
tte@cs.fau.de

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