Subject: Re: [Gendispatch] I-D Action: draft-nottingham-where-does-that-come-from-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Mar 2021 09:53:53 +1300

As already  noted, this can't really be an IETF document since it purports to cover all streams.

>  2.1.3. Proposal 3: domain usage 

I think this section is actively harmful. The canonical place for all RFCs is rfc-editor.org; I think that we should very likely deprecate copies in any other domains (although those domains should certainly have pointers to the canonical copies).

Really, RFCs have no place in the IETF data tracker, except as pointers.

>  2.2. Internet-Drafts
> 
> The following recommendations apply to the publication of Internet-Drafts.

The problem here is that draft-foo-bar has no intrinsic link to any of the streams. A differentiation can only be made later, if the draft becomes draft-ietf-bar or draft-irtf-bar. So how would we algorithmically classify draft-nottingham-quic-new-idea or draft-nottingham-where-does-that-come-from?

Regards
   Brian

On 12-Mar-21 14:44, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Clarifying IETF Document Status
>         Author          : Mark Nottingham
> 	Filename        : draft-nottingham-where-does-that-come-from-00.txt
> 	Pages           : 7
> 	Date            : 2021-03-11
> 
> Abstract:
>    There is widespread confusion about the status of Internet-Drafts and
>    RFCs, especially regarding their association with the IETF and other
>    streams.  This document recommends several interventions to more
>    closely align reader perceptions with actual document status.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-nottingham-where-does-that-come-from/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-nottingham-where-does-that-come-from-00.html
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 12 Mar 2021 19:42:58 -0500

> Really, RFCs have no place in the IETF data tracker, except as pointers.

Given the long history and very widespread practice of mirroring RFCs to 
numerous sites, and having seen many times how useful this can be, I 
really doubt it's a good idea to start discouraging this practice, even 
by the ietf.org site.

(now if ietf.org wants to mirror RFCs at rfc-mirrors.ietf.org and issue 
redirects to the latter domain, that probably wouldn't bother me)

Relying entirely on a single site makes things more fragile, and RFCs 
should IMO be widely replicated in order to limit the potential for 
access to them to be restricted either accidentally or deliberately.   
(It's not  as if RFCs never say things that are inconvenient to powerful 
parties.)

> The problem here is that draft-foo-bar has no intrinsic link to any of the streams. A differentiation can only be made later, if the draft becomes draft-ietf-bar or draft-irtf-bar. So how would we…

Maybe we don't need to solve that problem.   IMO even I-Ds that have 
been adopted by a working group are still not blessed by IETF and 
shouldn't be given any elevated status in the minds of the general 
public until they've been published in final form.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Mar 2021 14:09:11 +1300

On 13-Mar-21 13:42, Keith Moore wrote:
> Given the long history and very widespread practice of mirroring RFCs to numerous sites, and having seen many times how useful this can be, I really doubt it's a good idea to start discouraging this practice, even by the ietf.org site.

I agree that lots of mirrors of the canonical versions is a Good Thing. Now that the RFC Editor is showing the htmlized version for older RFCs, as well as the modern html versions, I think we should encourage all mirrors to carry them too. But what the draft seems to suggest is a *partial* mirror. That's a Bad Idea IMHO.
 
> (now if ietf.org wants to mirror RFCs at rfc-mirrors.ietf.org and issue redirects to the latter domain, that probably wouldn't bother me)
> 
> Relying entirely on a single site makes things more fragile, and RFCs should IMO be widely replicated in order to limit the potential for access to them to be restricted either accidentally or deliberately.   (It's not  as if RFCs never say things that are inconvenient to powerful parties.)
> 
>>>  2.2. Internet-Drafts
>>>
> Maybe we don't need to solve that problem.   IMO even I-Ds that have been adopted by a working group are still not blessed by IETF and shouldn't be given any elevated status in the minds of the general public until they've been published in final form.

Well, that's a bit vague in the draft. If it was more precisely defined, we could discuss it further.

    Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 13 Mar 2021 01:14:21 +0000

It’s silly to try and have one “official” place for RFC’s, and deprecate all other locations.  Even if it could be done, and I’d like to know why, we want these docs to be widely and freely available.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Mar 2021 14:22:35 +1300

> It’s silly to try and have one “official” place for RFC’s, and deprecate all other locations.  Even if it could be done, and I’d like to know why, we want these docs to be widely and freely availab…

Yes, in fact I agree, see my reply to Keith.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Sat, 13 Mar 2021 09:17:29 +0100

This having been said, I agree with Mark that this is a problem, that branding can help, and that the matter should get addressed.  Where it gets addressed is a matter of timing.  I really do hope that we can dispatch this work to the new WG-like structure that is being contemplated in the program.

Eliot

> On 13 Mar 2021, at 02:22, Brian E Carpenter <[email-masked]> wrote:
> 
> --
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch

---

From: Keith Moore <[email-masked]>
Date: Sat, 13 Mar 2021 09:33:58 -0500

On 3/13/21 3:17 AM, Eliot Lear wrote:

> This having been said, I agree with Mark that this is a problem, that branding can help, and that the matter should get addressed.

Agree with this much.   Especially now that HTML and PDF are widely used 
for RFCs, it seems reasonable to include logos in the HTMLized and PDF 
versions of newly produced RFCs, and perhaps also HTMLized and PDF 
versions of older RFCs.

But these seem a bit out of scope for IETF to specify in detail, so 
perhaps should be limited to brief recommendations to the RFC Editor.

I don't think Internet-Drafts should be stamped by IETF at all, but 
maybe authors should be able to specify one or more small logos of the 
organizations that they represent, if they wish.   If this is done I 
recommend that they be on a (single) cover/title page that doesn't 
change the format of the remainder of the draft.

Keith

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 15 Mar 2021 14:58:53 +1100

Hi Brian,

> On 13 Mar 2021, at 7:53 am, Brian E Carpenter <[email-masked]> wrote:
> 

Some parts will need to be initiated by other streams, but they stream managers can effectively opt into its suggestions. Also, much of it is about what it *not* associated with the IETF -- which we do control.

> Really, RFCs have no place in the IETF data tracker, except as pointers.

If we can cure ourselves of the addition to the augmented views on tools and datatracker, I'm all for this. What we really need to encourage is augmentation of the RFC Editor view (perhaps on the metadata page, etc.).

> The problem here is that draft-foo-bar has no intrinsic link to any of the streams. A differentiation can only be made later, if the draft becomes draft-ietf-bar or draft-irtf-bar. So how would we…

As unassociated drafts on internet-drafts.org; they're not adopted on any stream.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Mar 2021 00:11:07 -0400

Mark, I think the whole game with domains is a mistake.
As others have said, the content (drafts, RFCs, ...) is mirrored in 
multiple places.  And we want people to do that.

Also, when it comes to drafts, it is actually important that individual 
drafts aimed at a working group be known to and easily visible by the 
working group.  So if folks are using things like the datatracker WG 
summary page, the drafts need to be there.  At which point putting them 
in a different domain is completely worthelss.

I don't object to putting logos on  different stream RFCs.  I don't know 
that it will help much.

Note that none of your changes would seem to help much with the most 
common consufion, namely informational or experimental IETF RFCs being 
treated as Standards Track RFCs by external promoters.  And no, I do not 
think the right answer is to remove Informational or Experimental RFCs.

And we already see folks (maybe deliberately, maybe accidentally) 
confusing individual or WG Internet Drafts with RFCs.  Even though any 
form of reference is completely different.

I don't see most of this document as usefully improving much of any of 
the many problems I have seen.

Yours,
Joel

PS: At least in my experience, folks don't generally conflate or 
misrepresent either IRTF or Independent Stream documents with IETF 
product.  Maybe if we could figure out why not, we could get more 
leverage for actually solving the problem.

PPS: My recommendation would be to not dispatch this document.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 15 Mar 2021 15:22:05 +1100

Hi Joel,

> On 15 Mar 2021, at 3:11 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> As others have said, the content (drafts, RFCs, ...) is mirrored in multiple places.  And we want people to do that.

I'm not proposing that we disallow people from mirroring drafts and RFCs - I see the value in mirroring, and even dabble in it myself.

What I'm proposing is that we not lend the IETF branding -- in the form of the domain name, which appears in the browser bar for tools and datatracker -- to any random draft that gets submitted. That's misleading as to its status, and is one of the reasons we see I-Ds cited as 'the IETF draft...'.

> Also, when it comes to drafts, it is actually important that individual drafts aimed at a working group be known to and easily visible by the working group.  So if folks are using things like the datatracker WG summary page, the drafts need to be there.  At which point putting them in a different domain is completely worthelss.

Nothing in the proposal prevents *linking* to drafts elsewhere on such a page.

> I don't object to putting logos on  different stream RFCs.  I don't know that it will help much.
> 
> Note that none of your changes would seem to help much with the most common consufion, namely informational or experimental IETF RFCs being treated as Standards Track RFCs by external promoters.  And no, I do not think the right answer is to remove Informational or Experimental RFCs.

That's indeed a problem, but personally I think we need to get this part of our house in order before we can tackle it.

> And we already see folks (maybe deliberately, maybe accidentally) confusing individual or WG Internet Drafts with RFCs.  Even though any form of reference is completely different.
> 
> I don't see most of this document as usefully improving much of any of the many problems I have seen.
> 
> Yours,
> Joel
> 
> PS: At least in my experience, folks don't generally conflate or misrepresent either IRTF or Independent Stream documents with IETF product.  Maybe if we could figure out why not, we could get more leverage for actually solving the problem.
>

---

From: Christian Huitema <[email-masked]>
Date: Sun, 14 Mar 2021 21:23:18 -0700

I am not sure that I agree with Mark. Or at least not entirely. Yes, the 
way we publish documents is confusing. But I am not sure that Mark's 
proposal is the best we can do.

Mark proposes to distinguish the various categories of RFC based on the 
stream in which they were published. I think that this classification 
overlaps and partially conflicts with the nature of the RFC, i.e. the 
label as standard, BCP, informational and experimental. I think it is 
important to distinguish standards and BCP documents from the rest, and 
that Mark's suggestion of an IETF branding is certainly a good idea. But 
it is not obvious that informational documents and independent stream 
documents should have different statuses, or even different branding. 
Similarly, it is not obvious that IRTF documents shall have different 
branding from informational or experimental documents from the IETF. It 
also seems that many IAB documents overlap with the BCP and 
informational categories, and that branding IAB and IETF documents 
differently may or may not be a good idea.

I am particularly sensitive to the attempt to differentiate branding of 
informational documents coming through the IETF and through the 
independent stream. One important function of the independent stream is 
to provide "checks and balances" to the IETF, and ensure that minority 
opinions are not silenced. A strong branding differentiation would 
weaken this function of checks and balances, by clearly marking the 
minority opinions as second class citizens.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Mar 2021 14:14:52 +0100

Hi Christian,

> On 15 Mar 2021, at 05:23, Christian Huitema <[email-masked]> wrote:
> 
> I am not sure that I agree with Mark. Or at least not entirely. Yes, the way we publish documents is confusing. But I am not sure that Mark's proposal is the best we can do.
> 

I’m not sure that I agree with everything in Mark’s proposal either, but I think we have to agree that this is a problem that has been bothering many people for a long time.

> Mark proposes to distinguish the various categories of RFC based on the stream in which they were published. I think that this classification overlaps and partially conflicts with the nature of the RFC, i.e. the label as standard, BCP, informational and experimental. I think it is important to distinguish standards and BCP documents from the rest, and that Mark's suggestion of an IETF branding is certainly a good idea. But it is not obvious that informational documents and independent stream documents should       have different statuses, or even different branding. Similarly, it is not obvious that IRTF documents shall have different branding from informational or experimental documents from the IETF. It also seems that many IAB documents overlap with the BCP and informational categories, and that branding IAB and IETF documents differently may or may not be a good idea.
> 
These documents do have different statuses.  The only real question is how they should best be distinguished.  And we have a lot of capabilities, with which to do so.  For instance, the logo of the IETF needn’t appear on non-IETF documents.  Also, one could imagine either a water mark that indicates that something isn’t a standard, or a header or a footer along those lines.  In fact, one could imagine that even being applied retroactively to HTML!

> I am particularly sensitive to the attempt to differentiate branding of informational documents coming through the IETF and through the independent stream. One important function of the independent stream is to provide "checks and balances" to the       IETF, and ensure that minority opinions are not silenced. A strong branding differentiation would weaken this function of checks and balances, by clearly marking the minority opinions as second class citizens.
> 
I don’t think this is the distinction over which to really worry.  The bigger concern is whether or not something is an IETF standard (proposed or full).  I also don’t see the harm in indicating consensus through a visual cue such as a logo.  In fact, I could imagine some really entertaining logos to indicate obsolescence or updating.

For example, in the upper right hand corner of the display:

I’m sure that someone with more of a creative graphics sense could have even more fun.  What the logo looks like is for the IETF to decide.  That the logo can be used is for the RFC Editor process to decide. Anyway, just food for thought.  [Oh and don’t even start on the color situation! ;-]

Eliot

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Mon, 15 Mar 2021 06:27:05 -0700 (PDT)

Gendisp, etc,
	Three comments inline marked [RWG].
Regards,
Rod

> I don't object to putting logos on  different stream RFCs.  I don't know 

[RWG] I agree that iw wont help much, but perhaps a pre/post very
concise clear statement of the status of a document might help.
People outside the IETF may not even know to look up in the corner
as to what the status: experimental/informational/etc actually means.

> form of reference is completely different.

[RWG] I have actually seen a rather large open source project propose
adopting an Individual Draft as a policy as if the IETF had
published that work as an RFC.  This is a dangeriously bad state
of affairs and is worth spending some time thinking about how
the IETF can minimize such mistakes.

> PPS: My recommendation would be to not dispatch this document.

[RWG]  Would it be worth creating a better document, or is this
a solution in need of a problem?

-- 
Rod Grimes                                                 [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Mar 2021 09:48:45 -0400

I am happy to discuss (somewhere?  by direct email?  on the IETF list? 
It is not the role of Gendispatch even if we are abusing it that way.) 
ideas for effective ways to keep internet drafts effective while better 
differentiating them.  I have no good ideas to offer, sorry.

Yours,
Joel

On 3/15/2021 9:27 AM, Rodney W. Grimes wrote:
 >> Joel Halpern wrote
...
> the IETF can minimize such mistakes.
...