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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Deborah;

Yes, I'm quite aware of MISSREF etc... And that we have no control on papers and other SDOs, to which I sometime contribute.
I followed your advice and mailed to the IEEE coordination.

And yes, I believe that updating the text is in order, for our own consistency. Sometimes, waying nothing is better than the wrong thing. It might be enough to indicate that our I-Ds are WIP. You'll note that ay some point we produced WG documents as working papers with the intention to never turn them to RFCs.

Keep safe;

Pascal


> -----Original Message-----
> From: BRUNGARD, DEBORAH A <[e-mail]>
> Sent: mardi 29 mars 2022 22:27
> To: Brian E Carpenter <[e-mail]>om>; Pascal Thubert
> (pthubert) <[e-mail]>om>; Eric Rescorla <[e-mail]>om>; Joel Halpern
> Direct <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: RE: [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re:
> Chair/datatracker tracking expired WG documents ?)
> 
> 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 <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: Monday, March 28, 2022 5:24 PM
> To: Pascal Thubert (pthubert) <[e-mail]>om>; Eric Rescorla
> <[e-mail]>om>; Joel Halpern Direct <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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!nMd2ztC3cg
> ksqshpIlBhKt2GgDXPW6R1_4S-
> Lsq_rcz7mHODSz1JMhrHDY79R2bHZa3tMurDJrLYRwm5HnpHFdG-Fg$ . If you think the
> Tao should also mention the "work in progress" exception, write to tao-
> [e-mail].
> 
> >
> > 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 <[e-mail]>
> > *Sent:* vendredi 25 mars 2022 18:23
> > *To:* Joel Halpern Direct <[e-mail]>
> > *Cc:* Pascal Thubert (pthubert) <[e-mail]>om>; [e-mail];
> [e-mail]
> > *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
> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
> <mailto:[e-mail]>>
> >     >> Sent: vendredi 25 mars 2022 12:02
> >     >> To: 'Toerless Eckert' <[e-mail] <mailto:[e-mail]>>; Pascal
> Thubert (pthubert)
> >     >> <[e-mail] <mailto:[e-mail]>>
> >     >> Cc: [e-mail] <mailto:[e-mail]>; rfc-interest@rfc-
> editor.org <mailto:[e-mail]>
> >     >> 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 <[e-mail] <mailto:wgchairs-
> [e-mail]>> On Behalf Of Henk
> >     >>>>> Birkholz
> >     >>>>> Sent: vendredi 25 mars 2022 10:40
> >     >>>>> To: Valery Smyslov <[e-mail]
> <mailto:[e-mail]>>; 'Toerless Eckert'
> >     >>>>> <[e-mail] <mailto:[e-mail]>>; 'Tools Team Discussion'
> <[e-mail] <mailto:[e-mail]>>;
> >     >>>>> [e-mail] <mailto:[e-mail]>
> >     >>>>> 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
> >     [e-mail] <mailto:[e-mail]>
> >     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
> > [e-mail]
> > https://urldefense.com/v3/__https://mailman.rfc-
> editor.org/mailman/listinfo/rfc-
> interest__;!!BhdT!nMd2ztC3cgksqshpIlBhKt2GgDXPW6R1_4S-
> Lsq_rcz7mHODSz1JMhrHDY79R2bHZa3tMurDJrLYRwm5Hnpw6e1-9Q$
> >