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

From: 'Toerless Eckert' <[email-masked]>
Date: Fri, 25 Mar 2022 11:48:00 +0100

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 <[email-masked]> On Behalf Of Henk Birkholz
> > Sent: vendredi 25 mars 2022 10:40
> > To: Valery Smyslov <[email-masked]>; 'Toerless Eckert'
> > <[email-masked]>; 'Tools Team Discussion' <[email-masked]>;
> > [email-masked]
> > 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
> > >
> > >
> 

-- 
---
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Mar 2022 07:01:56 -0400

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

---

From: 'Toerless Eckert' <[email-masked]>
Date: Fri, 25 Mar 2022 13:05:55 +0100

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:
> 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
> 

-- 
---
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Mar 2022 12:21:43 +0000

This could be useful information to know. Does the liaison program not handle it?

A potential problem is that, unless people (who, that's also a problem) are diligent about following up and discouraging such use, then it is very easy for the misbehaving SDO to say "but you never complained so we assumed it's okay."

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Mar 2022 12:56:36 +0000

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

> From: Joel M. Halpern <[email-masked]>
> Sent: vendredi 25 mars 2022 12:02
> To: 'Toerless Eckert' <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: 3rd party SDO cross-referencing of IETF work (was: Re:
> Chair/datatracker tracking expired WG documents ?)
> 
> 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
> 
> > 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.
> >
> > 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
> >
> >> 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.
> >>
> >> 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
> >>
> >>> 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.
> >>>
> >>>>> 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

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 25 Mar 2022 09:41:55 -0400

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

---

From: 'Toerless Eckert' <[email-masked]>
Date: Fri, 25 Mar 2022 15:16:08 +0100

> A potential problem is that, unless people (who, that's also a problem) are diligent about following up and discouraging such use, then it is very easy for the misbehaving SDO to say "but you never…

True. I am hoping that if we tool this appropriately, then it will make life
easier for both sides (external SDO and us), and thats why its hopefully used.

Of course, appropriate tooling would mean that whereever you click for
"bibtex" (to this document) on datatracker, there would then have to be a better
option making it easy to register a referencing external SDO document
(at least that my starting bid ;-)

Cheers
    Toerless

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Mar 2022 10:23:12 -0700

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 <
[email-masked]> wrote:

> > 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
> >
> I-Ds
> write
> >>> Everybody who writes an external document could create such a
> third-party
> >> reference.
> _______________________________________________
> rfc-interest mailing list
> [email-masked]
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2022 09:55:12 +1300

Why should we care if some other SDO is happy to publish a "standard" with a normative dependency on a document whose preamble includes these words:

'Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."'

This is not our problem.

Trying to maintain cited-by pointers is approximately impossible. TimBL knew that, which is why the Web succeeded where other distributed hypertext projects failed. While I see why Toerless would like it, I don't think we can have it in the real world.

Regards
    Brian Carpenter

---

From: Melinda Shore <[email-masked]>
Date: Fri, 25 Mar 2022 13:02:55 -0800

On 3/25/22 12:55 PM, Brian E Carpenter wrote:
> Why should we care if some other SDO is happy to publish a "standard" 
> with a normative dependency on a document whose preamble includes these 
> words [ ... ]:

Right - that seems completely outside our purview.

What is a relevant question, I think, from an information management
perspective, is whether or not expired drafts have stable identifiers
and stable locations.  That can be useful for us, aside from the matter
of what other organizations do or do not do.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 25 Mar 2022 22:10:19 +0000

+1 Brian

Pascal and Toerless - To me, you are both focusing on different targets.

Pascal is concerned on IEEE references - Pascal, why not bring this up at the IEEE coordination meeting?

Toerless - while we can hope other SDOs/Forums/run-by-the-night groups would not normatively reference IETF wg drafts or individual drafts, there's not much we can do. Maybe that other group allows it. I've seen where contributions are accepted which point at IETF individual drafts. Even after the group was "educated" on it by a concerned member. When it comes to publishing standards, the traditional SDOs (e.g. ITU) do have "rules". But the rules are the rules of that SDO. Just as IETF has guidelines, e.g. in the Shepherd writeup and IESG review, the normative references are reviewed if they are "in an unclear state", "publicly available". And SDOs recognize what is referenced may not be up-to-date as there is always a window of time, ITU has a disclaimer on it in their Recommendations saying a user is encouraged to investigate the most recent Recommendation or other reference. Maybe IETF should add something explicitly if you think it would help.

If want to ask the IAB more on it, send mail to [email-masked]. I'm now on it, Toerless/Pascal, anytime want to chat, let's setup a virtual bar meet-
Deborah

-----Original Message-----
From: WGChairs <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Friday, March 25, 2022 4:55 PM
To: Salz, Rich <rsalz=[email-masked]>; 'Toerless Eckert' <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [rfc-i] Re: 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)

This is not our problem.

Regards
    Brian Carpenter

On 26-Mar-22 01:21, Salz, Rich wrote:
> https://urldefense.com/v3/__https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest__;!!BhdT!iXBZLT9G4A-tWxS-wnsthZyOm-QjLtb8WyNa_Y_OOKMbeD9nt9WJvnF0crY1s4P1TTLqZSarkTo6Vsg9OmCwiC0iZA$ 
>

---

From: Keith Drage <[email-masked]>
Date: Sat, 26 Mar 2022 21:06:54 +0000

To be honest, the only role I see for IETF in this discussion is 
education, i.e. to make clear to any SDO that happens to be using an 
IETF document as to what the status of that type of document is, 
primarily as to its stability, and likelihood to change. Of course, if 
an SDO sends a message concerning a particular document, then an honest 
reply is needed, and the prior work done in this area, e.g. between IETF 
and 3GPP is essential.

Whether a normative reference to an IETF document is a valid reference 
or not is govered by the rules of the SDO owning the document making the 
reference, not by the IETF. Essentially a normative reference is a macro 
call - at the point where a normative reference appears in an SDOs 
document, the reader inserts the referenced text from that referenced 
document. If an SDO publishes a document with a normative reference to 
an unstable document, then that is a problem between that SDO and their 
readership, and not one that belongs directly to IETF.

Of course the owners of any IPR in an IETF document that is so 
normatively referenced may also want to declare IPR against that SDOs 
referencing document, but that comes down to the owner of the IPR to 
handle, not the IETF.

regards

Keith

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Mar 2022 05:35:34 +0000

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.
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.”
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.

Sometimes someone raises the issue with the status of I-Ds and we get into endless discussions, I faced that again recently at ETSI.

What so you think?

Pascal

From: Eric Rescorla <[email-masked]>
Sent: vendredi 25 mars 2022 18:23
To: Joel Halpern Direct <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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.

Yours,
Joel

On 3/25/2022 8:56 AM, Pascal Thubert (pthubert) wrote:
>> From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
>> To: 'Toerless Eckert' <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert)
>> <[email-masked]<mailto:[email-masked]>>
>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>>> From: WGChairs <[email-masked]<mailto:[email-masked]>> On Behalf Of Henk
>>>>> Birkholz
>>>>> To: Valery Smyslov <[email-masked]<mailto:[email-masked]>>; 'Toerless Eckert'
>>>>> <[email-masked]<mailto:[email-masked]>>; 'Tools Team Discussion' <[email-masked]<mailto:[email-masked]>>;
>>>>> [email-masked]<mailto:[email-masked]>

_______________________________________________
rfc-interest mailing list
[email-masked]<mailto:[email-masked]>
https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Mar 2022 10:23:35 +1300

Pascal,

> 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 [email-masked].

> 
> 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 datatracke…

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 <[email-masked]>
> *Sent:* vendredi 25 mars 2022 18:23
> *To:* Joel Halpern Direct <[email-masked]>
> *Cc:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)
> 
> On Fri, Mar 25, 2022 at 6:42 AM Joel Halpern Direct <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     >> From: Joel M. Halpern <[email-masked] <mailto:[email-masked]>>
>     >> To: 'Toerless Eckert' <[email-masked] <mailto:[email-masked]>>; Pascal Thubert (pthubert)
>     >> <[email-masked] <mailto:[email-masked]>>
>     >> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     >>>>> From: WGChairs <[email-masked] <mailto:[email-masked]>> On Behalf Of Henk
>     >>>>> Birkholz
>     >>>>> To: Valery Smyslov <[email-masked] <mailto:[email-masked]>>; 'Toerless Eckert'
>     >>>>> <[email-masked] <mailto:[email-masked]>>; 'Tools Team Discussion' <[email-masked] <mailto:[email-masked]>>;
>     >>>>> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>
> 
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 29 Mar 2022 20:27:02 +0000

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 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Monday, March 28, 2022 5:24 PM
To: Pascal Thubert (pthubert) <[email-masked]>; Eric Rescorla <[email-masked]>; Joel Halpern Direct <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [rfc-i] 3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)

Pascal,

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 [email-masked].

    Brian

>     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$ >
> 
> 
> https://urldefense.com/v3/__https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest__;!!BhdT!nMd2ztC3cgksqshpIlBhKt2GgDXPW6R1_4S-Lsq_rcz7mHODSz1JMhrHDY79R2bHZa3tMurDJrLYRwm5Hnpw6e1-9Q$ 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 Mar 2022 21:47:50 +0000

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

In fact, the current version of the Tao (maintained at https://github.com/ietf/tao) doesn't have that language, but instead just points to BCP 9. Phrases like "work in progress" are also removed, pointing to BCP 9.

We only just finished editing/merging before IETF 113, and there wasn't time to update the website.  Please take a look at the GitHub repo and see if the language there needs to be fixed.

I think Valery's point got lost :(

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2022 13:59:17 +1300

Hi Rich,

I can't reduce this to a PR. It seems to me that the proposed new text for the Tao has lost some very important parts of the old text. It doesn't state that I-Ds expire after 6 months (which they still do, unless we amend RFC 2026), it doesn't underline that "They are most definitely not standards" and it doesn't state that they must only be cited as "work in progress". There's no need to quote BCP 9, but I think the points should be made.

Also, BTW, as well as mentioning the optional Privacy Considerations, why not mention the optional Implementation Status section (RFC7942 = BCP 205)?

Regards
    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Mar 2022 21:02:26 -0400

I want to reinforce Brian's point that you seem to be removing important 
things.

Who is doing this editing?

Yours,
Joel

On 3/29/2022 8:59 PM, Brian E Carpenter wrote:
> Hi Rich,
> 
> I can't reduce this to a PR. It seems to me that the proposed new text 
> for the Tao has lost some very important parts of the old text. It 
> doesn't state that I-Ds expire after 6 months (which they still do, 
> unless we amend RFC 2026), it doesn't underline that "They are most 
> definitely not standards" and it doesn't state that they must only be 
> cited as "work in progress". There's no need to quote BCP 9, but I think 
> the points should be made.
> 
> Also, BTW, as well as mentioning the optional Privacy Considerations, 
> why not mention the optional Implementation Status section (RFC7942 = 
> BCP 205)?
> 
> Regards
>     Brian
> 
>> In fact, the current version of the Tao (maintained at 
>> https://github.com/ietf/tao) doesn't have that language, but instead 
>> just points to BCP 9. Phrases like "work in progress" are also 
>> removed, pointing to BCP 9.
>>
>> We only just finished editing/merging before IETF 113, and there 
>> wasn't time to update the website.  Please take a look at the GitHub 
>> repo and see if the language there needs to be fixed.
>>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 29 Mar 2022 20:21:17 -0500

Hi Joel -

Github at least gives some insight into your question below.

See https://github.com/ietf/tao/commits/main

RjS

On 3/29/22 8:02 PM, Joel M. Halpern wrote:
> I want to reinforce Brian's point that you seem to be removing 
> important things.
>
>> I can't reduce this to a PR. It seems to me that the proposed new 
>> text for the Tao has lost some very important parts of the old text. 
>> It doesn't state that I-Ds expire after 6 months (which they still 
>> do, unless we amend RFC 2026), it doesn't underline that "They are 
>> most definitely not standards" and it doesn't state that they must 
>> only be cited as "work in progress". There's no need to quote BCP 9, 
>> but I think the points should be made.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Mar 2022 22:00:02 -0400

I fear I am missing something in the process.  Is there a procedure for 
community or IESG review of the text before it goes live?

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2022 15:14:53 +1300

Well, that was what the tao-discuss list was set up for, and I
confess that I left that list a long time ago. However, judging
by https://mailarchive.ietf.org/arch/browse/tao-discuss/, there
hasn't been much substantive discussion there**, and (as often
observed) design-team style work on GitHub does not in any way
approach a community consensus process.

So, for this fairly important chunk of our web site, can we please
have a diff to look in some digestible format, and some community
review? If that happens on tao-discuss, I'd be happy to rejoin.

Regards
    Brian Carpenter

** 119 messages since July 2012

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Mar 2022 08:12:15 +0200

> 'Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as refer…

Process confabulation at its finest.

This *SHOULD NOT* be our problem, in what some of us might consider an ideal world.  FTFY.

But it very often is.

When CoAP was done in 2013, the RFC got stuck on normative references to two security documents(*) that inexplicably took another year to emerge.
Referencing the approved I-D was *exactly* the right thing for an SDO to do during this time.

Beyond that, often documents are at a 95 % state for a *long* time before being approved, but can’t get approved until the last i is dotted.
An SDO may have schedules that make them publish documents that are fine with a reference to a 95 % or 98 % ready state.

(Other SDOs may also simply want to use work before *our* quality standards consider it ready — there is a reason other SDOs have rather varying quality objectives, often trading quality for velocity.  We may consider that unfortunate or even detrimental, but we are better off knowing that this has happened than ignoring an emerging installed base.  And I’d rather have them *reference* our I-D than copy-paste text.)

> Trying to maintain cited-by pointers is approximately impossible. TimBL knew that, which is why the Web succeeded where other distributed hypertext projects failed. While I see why Toerless would l…

That is a separate discussion that I think derailed a bit here.

I believe that collecting incoming references (whether I-Ds or RFCs) is a worthwhile effort, even if the result will have only quite partial coverage in many cases (sometimes to an extent that it is not useful, say for RFC 793).  Giving SDOs or alliances a way to indicate such a reference early (even while the referenced document is still I-D) can help us with planning and should be encouraged.  The technical process for this might be modeled after the IPR disclosure process.

Grüße, Carsten

(*) The delay also all but killed attention to the approaches provided by these security documents, so we should have excised the reference to them/put them into a separate document and published the referencing document with a gaping hole.
We need better process tools for dealing with such delays — instead of letting a document perish in the RFC editor queue, we need to be able to do emergency publications based on emerging (emergency?) delays (**).
But that is yet another discussion we can’t ignore — at least this one is partially relevant for Rfc-interest…

(**) The average MISSREF age in queue is > 40 weeks [1] — i.e. the average sojourn time once caught in that limbo is likely beyond a year and a half.

[1]: https://www.rfc-editor.org/reports/CurrQstats.txt

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Mar 2022 14:13:23 +0000

Given that the GitHub repo has existed since 2018 and that the tao-discuss list has been ineffective, doing the poorly-defined work to make a diff "digestible" so that you can join a list and make comments is not something I'm willing to do at this point in time.

I assume you know how to use wget and the unix diff utility. :)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Mar 2022 14:22:21 +0000

Should the Tao be yet another definitive document on everything IETF, or should It be enough to convey the "sense" of the IETF? I am most definitively in the latter camp. I base this view on having given the newcomer's tutorial *MANY* times, been heavily involved with EMODIR and its predecessor for years, and having countless discussions with newcomers at various meet and greets, guides/mentors, etc.

I have copied Brian's comments into an issue which you can find at https://github.com/ietf/tao/issues/44

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Mar 2022 10:40:01 -0400

As far as I can tell, the answer to that either / or question is "yes".
That is, as I understand it there is no intention that the tao be 
comprehensive.  it is intended to be a starting point.  It is also 
important that it not be misleading  And that it cover the important 
points we as community consider important for newcomers.

For example, the point that I-Ds are not standards is something folks 
get wrong, something some marketers mislead about, and something that is 
important to understand in working in the process.

Yours,
Joel

On 3/30/2022 10:22 AM, Salz, Rich wrote:
> Should the Tao be yet another definitive document on everything IETF, or 
> should It be enough to convey the "sense" of the IETF? I am most 
> definitively in the latter camp. I base this view on having given the 
> newcomer's tutorial *MANY* times, been heavily involved with EMODIR and 
> its predecessor for years, and having countless discussions with 
> newcomers at various meet and greets, guides/mentors, etc.
> 
> <https://github.com/ietf/tao/issues/44>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Mar 2022 14:41:07 +0000

+1 to stay very abstract / intent level 😊

From: WGChairs <[email-masked]> On Behalf Of Salz, Rich
Sent: mercredi 30 mars 2022 16:22
To: Joel M. Halpern <[email-masked]>; Brian E Carpenter <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Tao [3rd party SDO cross-referencing of IETF work (was: Re: Chair/datatracker tracking expired WG documents ?)]

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Mar 2022 14:46:17 +0000

Shrug, we disagree. If we haven't found the text that appears on the front-matter of every single draft to be compelling enough, then adding more words to an overview document will not change things.  YMMV, which is shorthand for we're not going to change each other's minds.

Neither list here is the appropriate discussion forum, so I'll stop now and point to https://www.ietf.org/mailman/listinfo/tao-discuss or the more likely to be useful https://github.com/ietf/tao/issues/44

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 30 Mar 2022 10:53:18 -0400

+1 to convey the "sense" of the IETF, if that is still possible.

On Wed, Mar 30, 2022 at 10:46 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> Shrug, we disagree. If we haven't found the text that appears on the
> front-matter of every single draft to be compelling enough, then adding
> more words to an overview document will not change things.  YMMV, which is
> shorthand for we're not going to change each other's minds.
>
> Neither list here is the appropriate discussion forum, so I'll stop now
> and point to https://www.ietf.org/mailman/listinfo/tao-discuss or the
> more likely to be useful https://github.com/ietf/tao/issues/44
>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Mar 2022 11:02:30 -0400

As I understand it, while you are one of the editors, the actual content 
decision resides with the IESG?  You will not be pushing anything to the 
IETF web site without their review?

Yours,
Joel

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Mar 2022 15:17:26 +0000

RFC 6722 is still in effect, yes.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Mar 2022 09:56:36 +1300

Carsten,
On 30-Mar-22 19:12, Carsten Bormann wrote:
>> 'Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."'
> Referencing the approved I-D was *exactly* the right thing for an SDO to do during this time.

And nobody stops them doing so. But the document they are citing is still 
a work in progress, and remains so until the RFC announcement comes out. It isn't hard for the referring document to say so.

> (Other SDOs may also simply want to use work before *our* quality standards consider it ready — there is a reason other SDOs have rather 
varying quality objectives, often trading quality for velocity.  We may consider that unfortunate or even detrimental, but we are better off knowing that this has happened than ignoring an emerging installed base.  And I’d rather have them *reference* our I-D than copy-paste text.)

I agree, and so would the IETF Trust, I assume.

> I believe that collecting incoming references (whether I-Ds or RFCs) is 
a worthwhile effort, even if the result will have only quite partial coverage in many cases (sometimes to an extent that it is not useful, say for 
RFC 793).  Giving SDOs or alliances a way to indicate such a reference early (even while the referenced document is still I-D) can help us with planning and should be encouraged.  The technical process for this might be 
modeled after the IPR disclosure process.

I'm pessimistic, judging by the experience we had with the "new work" mailing list. Does that still exist?

     Brian

> But that is yet another discussion we can’t ignore — at 
least this one is partially relevant for Rfc-interest…

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Mar 2022 10:04:45 +1300

> RFC 6722 is still in effect, yes.

And that's fine. All I'm saying is that for what looks like a fairly large
update of something we suggest that all newcomers read, a community review
is normal IETF practice.

As for the diffs, this is actually quite hard as a direct result of moving
the Tao from RFC to web-content format. Is the current posted version
available in Markdown somewhere?

    Brian

---

From: Robert Sparks <[email-masked]>
Date: Wed, 30 Mar 2022 16:19:10 -0500

> available in Markdown somewhere?

This should be easy, but the repo currently doesn't do what it says it 
will do?

The README.md at the repo says there is a `published` branch and some 
tags, but I find neither.

Niels - how do we see what commit was published last?

Guessing, and using the internal 2018-11-08 timestamp inside the 
document at https://www.ietf.org/about/participate/tao/, it would be 
ae31db5.

If I've done it right, this should show the diff since then:

https://github.com/ietf/tao/compare/ae31db5..HEAD?short_path=b335630#diff-ecfe4e76d8fa0c495b999a60e0c158dc00d7b588d1aad76dd2aeae1f53f66c16

If that's _doesn't_ compare against what's currently published, apologies.

RjS

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 31 Mar 2022 12:38:28 +0200

Hi all,

On 30-03-2022 23:19, Robert Sparks wrote:
> This should be easy, but the repo currently doesn't do what it says it will do?
> 
> The README.md at the repo says there is a `published` branch and some tags, but I find neither.
> 

This is the published text:
https://github.com/ietf/tao/blob/ae31db516c1c5cade50a25640f528bb36e81bc5e/Tao.md

We are currently making the changes as described on the Github, but we haven't made a new revision since we instated this process. That is why the Github repo is not completely up to date yet. But a new possible revision will be published soon here: https://www.ietf.org/about/participate/tao/tao-possible-revision/ as described in RFC6722.

> Guessing, and using the internal 2018-11-08 timestamp inside the document at https://www.ietf.org/about/participate/tao/, it would be ae31db5.
> 

Indeed

> https://github.com/ietf/tao/compare/ae31db5..HEAD?short_path=b335630#diff-ecfe4e76d8fa0c495b999a60e0c158dc00d7b588d1aad76dd2aeae1f53f66c16

That is correct.

Discussion is very welcome on tao-discuss (https://www.ietf.org/mailman/listinfo/tao-discuss) or PRs and issues on Github.

Best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Affiliated Faculty - Digital Democracy Institute - Simon Fraser University
Non-Resident Fellow 2022-2023 - Center for Democracy & Technology
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas
Research Fellow - Centre for Internet and Human Rights - European University Viadrina

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my latest article on Internet infrastructure governance in Globalizations here: https://www.tandfonline.com/doi/full/10.1080/14747731.2021.1953221

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Mar 2022 13:11:03 +0000

Wgchairs and rfc-interest to bcc; please use tao-discuss.

Is that really the case?  We generally don't get community feedback on
	- all other www.ietf.org content
	- sponsorship logo's
	- newcomer's slides
	- newcomer's emails that go out
Have we ever?  Those things are just as likely to be seen by newcomers, arguably more so. Seems to me that the Tao is an outliner, and a 6722-bis saying that it should be treated like all other www.ietf.org content is worth doing.

I don't know; I just wrote the editors and asked where I could suggest changes. But maybe some on tao-discuss does. If you pull down the git repo and use the commandline, commit dae5894fb8b5bcc848fe0c3493bd732c8bd9a033 seems to be the last one before I started making suggestions (er, pull requests [PRs]).  I did mine a section at a time, and almost always stayed within the section, so looking for my commits might be good enough.