Subject: Does being an RFC mean anything?

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 11 Mar 2009 12:22:31 -0700

The recent threads about draft-housley-tls-authz have taught me something I
didn't know about IETF, and I don't like what I've learned.

There are, it appears, many types of IETF RFCs, some which are intended to
be called "Internet standards" and others which bear other embedded labels
and descriptions in their boilerplate text that are merely "experimental" or
"informational" or perhaps simply "proposed standard". One contributor here
described the RFC series as "a repository of technical information [that]
will be around when I am no longer around." 

The world is now full of standards organizations that treat their works as
more significant than merely "technical information." Why do we need IETF
for that purpose? If all we need is a repository of technical information,
let's just ask Google and Yahoo to build it for us. Maybe our Internet
standards should instead be created in an organized body that pays serious
attention to the ability of the wide world to implement those standards
without patent encumbrances. 

But even if IETF isn't willing to amend its patent policy that far-and most
SDOs still aren't, unfortunately-at the very least we should take our work
seriously. When someone proposes a serious RFC, we should demand that the
water around that RFC be swept for mines-especially *disclosed* patent mines
that any serious sailor would want to understand first.

If IETF isn't willing to be that serious, maybe we should recommend that our
work go to standards organizations that do care? As far as my time to
volunteer for a better Internet, there are far better ways to do it than
listening here to proposals that are merely "technical information." At the
very least, separate that into a different list than IETF.org so I know what
to ignore!

By the way, many of the same companies and individuals who are involved here
in IETF are also active participants in W3C, OASIS, and the new Open Web
Foundation, all of which organizations pay more attention to patents and the
concept of "open standards" than what IETF seems to be doing here. So let's
not be disingenuous, please. Almost everyone here has previous experience
doing this the right way. 

/Larry

Lawrence Rosen

Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)

3001 King Ranch Road, Ukiah, CA 95482

707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243

Skype: LawrenceRosen

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 11 Mar 2009 14:57:02 -0500

Larry,

I have to apologize in advance for even posting this followup, but...

The IETF is pretty clear that there are different kinds of RFCs, down to the level of April Fools Day RFCs,

The world outside the IETF is not, and

We don't seem to worry about that disconnect in the IETF.

At the end of the day, we are who we are. That might change, but won't change based on posting to this mailing list.

Spencer
  ----- Original Message ----- 
  From: Lawrence Rosen 
  To: [email-masked] 
  Sent: Wednesday, March 11, 2009 2:22 PM
  Subject: Does being an RFC mean anything?

  The recent threads about draft-housley-tls-authz have taught me something I didn't know about IETF, and I don't like what I've learned.

  There are, it appears, many types of IETF RFCs, some which are intended to be called "Internet standards" and others which bear other embedded labels and descriptions in their boilerplate text that are merely "experimental" or "informational" or perhaps simply "proposed standard". One contributor here described the RFC series as "a repository of technical information [that] will be around when I am no longer around." 

  The world is now full of standards organizations that treat their works as more significant than merely "technical information." Why do we need IETF for that purpose? If all we need is a repository of technical information, let's just ask Google and Yahoo to build it for us. Maybe our Internet standards should instead be created in an organized body that pays serious attention to the ability of the wide world to implement those standards without patent encumbrances. 

  But even if IETF isn't willing to amend its patent policy that far-and most SDOs still aren't, unfortunately-at the very least we should take our work seriously. When someone proposes a serious RFC, we should demand that the water around that RFC be swept for mines-especially *disclosed* patent mines that any serious sailor would want to understand first.

  If IETF isn't willing to be that serious, maybe we should recommend that our work go to standards organizations that do care? As far as my time to volunteer for a better Internet, there are far better ways to do it than listening here to proposals that are merely "technical information." At the very least, separate that into a different list than IETF.org so I know what to ignore!

  By the way, many of the same companies and individuals who are involved here in IETF are also active participants in W3C, OASIS, and the new Open Web Foundation, all of which organizations pay more attention to patents and the concept of "open standards" than what IETF seems to be doing here. So let's not be disingenuous, please. Almost everyone here has previous experience doing this the right way. 

  /Larry

  Lawrence Rosen

  Skype: LawrenceRosen

------------------------------------------------------------------------------

  _______________________________________________
  Ietf mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Mar 2009 13:06:40 -0700

Spencer Dawkins wrote:
  > The IETF is pretty clear that there are different kinds of RFCs,

We even produced an RFC about it:

    Not All RFCs are Standards

    <http://www.rfc-editor.org/rfc/rfc1796.txt>

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Mar 2009 16:08:04 -0400

On 11 Mar 2009, at 15:22, Lawrence Rosen wrote:

> The world is now full of standards organizations that treat their  
> works as more significant than merely "technical information." Why  
> do we need IETF for that purpose?

The RFC series is an ongoing record of the technical underpinnings of  
the Internet.

Part of those underpinnings are standards, in the interests of  
interoperability. Other parts are records of the Internet's culture,  
of how people use the Internet, of good ideas that went nowhere and of  
bad ideas that were thrown away.

Having all these things in a single collection of documents is good  
for archival, research and citation as well as being good for software  
development and engineering. The continuity of the ongoing effort  
benefits from this documentation. You suggest that the archival of  
mere "technical information" implies that the IETF is not "serious". I  
think that depends very much on your idea of what "serious" means.

Joe

---

From: Ofer Inbar <[email-masked]>
Date: Wed, 11 Mar 2009 15:24:05 -0500

> will be around when I am no longer around." 

I was also under the impression that a lot of RFCs are *not* "IETF RFCs",
since the RFC editor will publish certain types of RFCs without them
having gone through an IETF process.  RFC as a document series is not
the same thing as "the IETF's publications"; the IETF publishes its
final products as RFCs, and so do some others, including individuals.
  -- Cos

---

From: Michael Loftis <[email-masked]>
Date: Wed, 11 Mar 2009 14:28:47 -0600

--On March 11, 2009 4:08:04 PM -0400 Joe Abley <[email-masked]> wrote:

> The RFC series is an ongoing record of the technical underpinnings of the
> Internet.

I have to agree with this.  The RFCs are a record of both success and 
failure.  Yes over time we've found better ways to do things, and that is 
also where the RFCs stand.  As a history book for the technical bedrock we 
all really on now.  Almost every human relies on this experiment we call 
the Internet.  The RFCs help to document how things are done, and how 
things WERE done.  The stewardship of this information is not to be taken 
lightly.  Having it available in one place and "on topic" as many might say 
is invaluable to anyone trying to develop an Internet based application, or 
doing research on the Internet itself.  Yes, there are discussions and 
working groups and everything.  But the RFCs are the Medical Journal and 
the peer reviewed information distilled from all of that and therefore each 
one embodies huge amounts of effort either on the part of an individual, a 
team of individuals, or a large group effort.

I personally feel that even "Informational" RFCs are invaluable, they do 
not define a standard, but instead clarify how something is (or was) used. 
The recent Syslog RFC (5424) mentioning the old BSD Syslog RFC (3164) is a 
great example.  3164 is informational in nature.  5424 obsoletes 3164 
because it tries to actually propose a standard, whereas 3164 just 
identified what was out there in the wild, and documented it.  It didn't 
try to tell anyone how to use syslog, just tried to make it known in a 
central place how it was being used.  This would be VERY valuable to anyone 
trying to write a syslog daemon, even without it defining any sort of 
protocol.

The information in the RFCs is (in my mind) intended primarily to increase 
interoperability between Internet enabled applications.  They do this by 
defining standards, by clarifying standards, by proposing standards, or 
simply by documenting observations of how things behave in the wild 
(whether or not those things are a standard).  All of this is extremely 
valuable research and information.  Having it in one place, and having it 
under the stewardship of an organization that desires to maintain it with 
that in mind is invaluable and necessary.

This organization must be atleast somewhat independent.  It's therefore not 
appropriate for Google, or Yahoo!, or Microsoft to maintain these bodies of 
standards.  Independent bodies must maintain them to ensure some level of 
fairness and public participation and to try to prevent tampering with the 
process (of recording and maintaining the archives and standards) and 
ensure integrity of the process.

> interoperability. Other parts are records of the Internet's culture, of
> how people use the Internet, of good ideas that went nowhere and of bad
> ideas that were thrown away.
>
> Having all these things in a single collection of documents is good for
> archival, research and citation as well as being good for software
> benefits from this documentation. You suggest that the archival of mere
> "technical information" implies that the IETF is not "serious". I think
> that depends very much on your idea of what "serious" means.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 11 Mar 2009 17:33:41 -0500

On 3/11/09 3:24 PM, "Ofer Inbar" <[email-masked]> wrote:
> having gone through an IETF process.

They certainly have gone through an IETF process to get
published, whether they're a working group document or
individual contribution.  That's how they end up being
published as RFCs.  Maybe there's some cloudiness around
the relationship between the RFC Editor and "the IETF."
There's certainly some murk around who is part of the
IETF.  And maybe the IETF is process, not people (that
would tend to explain a lot).

>From a librarian perspective, the RFCs are a document
series.  That's a problem insofar as the IETF is perceived
to be a standards body.  Certainly in bodies like ETSI
there's an explicit distinction between a "technical
standard" and a "technical report" that I think may
be clearer than the distinctions among IETF standards,
IETF best practices documents, IETF experimental
standards, IETF informational documents, and then
orthogonally the various routes to publication.

Melinda

---

From: James Aldridge <[email-masked]>
Date: Wed, 11 Mar 2009 23:52:25 +0000

> orthogonally the various routes to publication.

Is this reallly a problem?

Yes, RFCs can be published for a multitude of reasons, but whether a
particular RFC is standards track, informational, experimental, historic, etc.
is clearly indicated in the rfc index file.

--James

---

From: TSG <[email-masked]>
Date: Wed, 11 Mar 2009 16:54:04 -0700

Lawrence Rosen wrote:

Because Larry - many of those here owe their ongoing $$$ livelihood to 
the lie the IETF has become. And so what you are suggesting is 
increasing the rolls of the unemployed by adding these individuals who's 
whole existence is the IETF. Its also these people in my opinion that 
make the IETF the laughingstock its become as you so rights notice that 
RFC's and the process for creating standards has degraded into a model 
where there really is no standard.

Just my two cents

Todd Glassey
>
> The recent threads about draft-housley-tls-authz have taught me 
> something I didn't know about IETF, and I don't like what I've learned.
>
> There are, it appears, many types of IETF RFCs, some which are 
> intended to be called "Internet standards" and others which bear other 
> embedded labels and descriptions in their boilerplate text that are 
> merely "experimental" or "informational" or perhaps simply "proposed 
> standard". One contributor here described the RFC series as "a 
> repository of technical information [that] will be around when I am no 
> longer around."
>
> works as more significant than merely "technical information." Why do 
> we need IETF for that purpose? If all we need is a repository of 
> technical information, let's just ask Google and Yahoo to build it for 
> us. Maybe our Internet standards should instead be created in an 
> organized body that pays serious attention to the ability of the wide 
> world to implement those standards without patent encumbrances.
>
> But even if IETF isn't willing to amend its patent policy that far—and 
> most SDOs still aren't, unfortunately—at the very least we should take 
> our work seriously. When someone proposes a serious RFC, we should 
> demand that the water around that RFC be swept for mines—especially 
> **disclosed** patent mines that any serious sailor would want to 
> understand first.
>
> If IETF isn't willing to be that serious, maybe we should recommend 
> that our work go to standards organizations that do care? As far as my 
> time to volunteer for a better Internet, there are far better ways to 
> do it than listening here to proposals that are merely "technical 
> information." At the very least, separate that into a different list 
> than IETF.org so I know what to ignore!
>
> By the way, many of the same companies and individuals who are 
> involved here in IETF are also active participants in W3C, OASIS, and 
> the new Open Web Foundation, all of which organizations pay more 
> attention to patents and the concept of "open standards" than what 
> IETF seems to be doing here. So let's not be disingenuous, please. 
> Almost everyone here has previous experience doing this the right way.
>
> /Larry
>
> Lawrence Rosen
>
> Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com 
> <http://www.rosenlaw.com>)
>
> ------------------------------------------------------------------------
>

---

From: Joe Baptista <[email-masked]>
Date: Wed, 11 Mar 2009 20:18:03 -0400

On Wed, Mar 11, 2009 at 7:54 PM, TSG <[email-masked]> wrote:

> Lawrence Rosen wrote:
>
> Because Larry - many of those here owe their ongoing $$$ livelihood to the
> lie the IETF has become. And so what you are suggesting is increasing the
> rolls of the unemployed by adding these individuals who's whole existence is
> the IETF. Its also these people in my opinion that make the IETF the
> laughingstock its become as you so rights notice that RFC's and the process
> for creating standards has degraded into a model where there really is no
> standard.

I agree.  I also remember over the years that many voices warned this was
coming.  I heard them.  Did anyone else?

cheers
joe baptista

>
>
> Just my two cents
>
> Todd Glassey
>
>>
>> The recent threads about draft-housley-tls-authz have taught me something
>> I didn't know about IETF, and I don't like what I've learned.
>>
>> most SDOs still aren't, unfortunately—at the very least we should take our
>> work seriously. When someone proposes a serious RFC, we should demand that
>> the water around that RFC be swept for mines—especially **disclosed** patent
>> mines that any serious sailor would want to understand first.
>>
>> If IETF isn't willing to be that serious, maybe we should recommend that
>> our work go to standards organizations that do care? As far as my time to
>> By the way, many of the same companies and individuals who are involved
>> here in IETF are also active participants in W3C, OASIS, and the new Open
>> Web Foundation, all of which organizations pay more attention to patents and
>> the concept of "open standards" than what IETF seems to be doing here. So
>> let's not be disingenuous, please. Almost everyone here has previous
>> experience doing this the right way.
>>
>> /Larry
>>
>> Lawrence Rosen
>>
>> Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com <
>> http://www.rosenlaw.com>)
>>

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

---

From: Ralf Weber <[email-masked]>
Date: Thu, 12 Mar 2009 01:20:17 +0100

Moin!

On 11.03.2009, at 20:22, Lawrence Rosen wrote:
> intended to be called "Internet standards" and others which bear  
> other embedded labels and descriptions in their boilerplate text  
> that are merely "experimental" or "informational" or perhaps simply  
> "proposed standard". One contributor here described the RFC series  
> as "a repository of technical information [that] will be around when  
> I am no longer around."
>
Every document published as an RFC has one of the tags you mention on  
it. So it exactly describes what's meant there. I can't see a problem  
with that. Technology advances and so should our standards, or best  
practises do. The IETF does this by publishing documents that are  
relevant to a technology in an open and documented process. A lot of  
stuff that is an RFC is updated or obsoleted by later documents and  
all of that is openly discussed and later documented.

However even that information published as RFCs might not be enough  
for someone to implement a protocol. My favorite current example is  
the contradiction of RFC3597 and RFC4034 on what DNS records have to  
be in canonical form. In that case the older RFC3597 was right and  
this has already been acknowledged in draft-ietf-dnsext-dnssec-bis- 
updates (http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnssec-bis-updates/ 
) however this has not yet become an official document aka RFC.

But even in that case the IETF process is totally open and anybody  
could follow this, and if I want to implement stuff in a certain area  
the IETF due to it's openness gives me all the necessary information  
to do that, and more than just the plain standards would describe. I  
see this as a positive and not a negative thing.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/
Data | Voice | Managed Services

Schütze Deine Umwelt | Erst denken, dann drucken

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland  
* Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *

Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies *  
Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 11 Mar 2009 17:31:27 -0700

If someone fails to read the front page of an RFC which clearly states what that document is and is not, that is their problem. There is no excuse for stupidity or laziness.

There is a real problem with people thinking that RFC == Free License. We need to educate people and maybe consider new ways to get that message out. But it has nothing to do with the status of the document. The purpose of RFCs is in the *name*: Request For Comments. How much more clear can you get? It is a memo publication channel for documents related to internet technologies. It is a way for people to communicate ideas and preserve them. Standards are just a small part of it.

There is no connection between the document status (standard, info, experimental, etc.) to its IPR status. Yes, most standards tend to be free, but that is still a document by document distinction. And to argue that it is different elsewhere is wrong. For example, OASIS has plenty of standards that are not free. I am willing to bet that there are more fee-based licensed standards in the world than free ones. You have to understand the wide range of topics discussed in the IETF and the fact that a lot of it might be of no consequences to open source developers. It is not the job of the IETF to fight against the patent system. What we need to make sure is that the communities creating standards ensure that their expected audience can implement it.

If you don't understand how something works, saying its broken is the lazy way out. Should we do a better job educating people about the IPR consequences of using RFCs? Of course! Should we make it harder for encumbered tech to make it into standards? Hell yeah! But we need to solve the problem where it belongs.

As for TSG's comments: show me an organization this size that doesn't have people who worry more about their ass than the community they are in. You comment makes as much sense as saying that you would not vote for president because politics is dirty and all about self promotion. Grow up.

EHL

On 3/11/09 3:54 PM, "TSG" <[email-masked]> wrote:

Lawrence Rosen wrote:

Just my two cents

Todd Glassey
> But even if IETF isn't willing to amend its patent policy that far-and
> most SDOs still aren't, unfortunately-at the very least we should take
> demand that the water around that RFC be swept for mines-especially

---

From: Dean Willis <[email-masked]>
Date: Wed, 11 Mar 2009 23:30:37 -0500

On Mar 11, 2009, at 2:22 PM, Lawrence Rosen wrote:

> do we need IETF for that purpose? If all we need is a repository of  
> technical information, let's just ask Google and Yahoo to build it  
> for us. Maybe our Internet standards should instead be created in an  
> organized body that pays serious attention to the ability of the  
> wide world to implement those standards without patent encumbrances.
>
> But even if IETF isn't willing to amend its patent policy that far— 
> and most SDOs still aren't, unfortunately—at the very least we  
> should take our work seriously. When someone proposes a serious RFC,  
> we should demand that the water around that RFC be swept for mines— 
> especially *disclosed* patent mines that any serious sailor would  
> want to understand first.
>
> that our work go to standards organizations that do care? As far as  
> my time to volunteer for a better Internet, there are far better  
> ways to do it than listening here to proposals that are merely  
> "technical information." At the very least, separate that into a  
> different list than IETF.org so I know what to ignore!
>
> involved here in IETF are also active participants in W3C, OASIS,  
> and the new Open Web Foundation, all of which organizations pay more  

I work in VoIP. My current day job is consulting on IPR, primarily on  
patent litigation defense.

There are tens of thousands of patents in this area in the US alone. I  
can think of few things I've seen in the last few years that aren't  
covered by some kind of patent when they are brought into IETF, and  
most of those acquire some kind of patent not long after. Many of the  
things I've seen I can't discuss for NDA reasons, but I can say that I  
accidentally found one patent that might possibly apply to an RFC I  
edited, for which I submitted a 3rd party IPR disclosure to test the  
process.

Even if we applied the entire administrative capacity of the IETF to  
filing and processing IPR disclosures, we couldn't possibly keep up  
with the applicable US patents applying to VoIP, much less the tens of  
thousands of patents on other protocols and in other jurisdictions.

I haven't looked, but I'm willing to bet that the same reality applies  
to every other SDO.

So get real. The ONLY thing that an SDO's IPR disclosure process helps  
with is the submarine patent held by an active participant in the SDO  
-- and look where that got us with FTC vs. Rambus in the long run. To  
the extent that the SDO disclosure policies apply, they apply equally  
to Standard, Informational, Experimental, and even Historical track  
RFCs. That's it -- if an IETF participant fails to disclose, they run  
risk of litigation around applying a patent against a standard, and  
the outcome is not a sure thing.

This is especially poignant in that the IETF does not have corporate  
membership. Rather, it has voluntary individual participation. So for  
example, if Employee A (who does not participate in the IETF)  at  
company X files an patent on Idea #12 but doesn't tell Employee B (who  
works on Idea #12 in the IETF), then it's arguable that Company X has  
no disclosure liability here.  For example, in the case I mentioned  
above where I filed the 3rd party notice, none of the participants  
from the IPR-owning company that I spoke to had been previously aware  
of the IPRs existence. Some attorney back in the home-country filed it  
based on a disclosure from somebody who probably wasn't even aware  
there was a need for a standard related to the idea.

Now, if you want to lobby for requiring corporate membership in IETF,  
feel free, but prepare for the throwing of a lot of stones. In the  
meantime, get over it. Trying to require IETF to do a patent search on  
every aspect of every RFC would just shut the organization down.

--
Dean Willis

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 11 Mar 2009 22:14:53 -0700

> -----Original Message-----
> From: Mohsen BANAN [mailto:[email-masked]]
> Sent: Wednesday, March 11, 2009 6:01 PM
> 
> >>>>> On Wed, 11 Mar 2009 17:31:27 -0700, Eran Hammer-Lahav
> <[email-masked]> said:
> 
>   Eran> There is no connection between the document status (standard,
> info,
>   Eran> experimental, etc.) to its IPR status.
> 
> You are dead wrong.
> 
> See Section 10.3.2 of RFC-2026.

If you are going to use strong language, you should at least make sure you are not contradicting yourself.

There is no connection between the document status to its IPR status. Any of the document types can have any IPR status. The only thing the section you referenced says in relation to this discussion is that if a disclosure is made, the IETF has to attempt to obtain a RAND license and either way, has to document the result of this effort.

> Note that after 13 years
>  RFC-2026 -- The Internet Standards Process --  Revision 3
>  October 1996
> is still the latest.
> 
> In other words, despite knowing about severe
> process problems nothing has been done for 13 years.
> 
> As I said before, the real problem is that even
> RFC-2026 is mostly imaginary and that IETF has
> become a cult dominated by interests of
> proprietary big business. As we are seeing.

My work obtaining licenses for open community specs and my role in the Open Web Foundation is all based on the view that standards should be free and unencumbered. There is nothing to prevent working groups from rejecting encumbered contribution or technology by consensus. Since the IETF process is completely open, it is easy for a committed community to make sure the right thing is done.

In addition, while the IETF process has indeed failed to catch-up with the time, the community around it is getting pretty sophisticated. The recent work of the FSF (no matter how misguided) is proof that the "little guy" still has a voice here. The entire IETF process depends on community consensus. There is no reason to significantly alter the culture and openness of this organization for something that can be accomplished via other means.

Big companies with deep pockets will find new avenues for their work if they don't like the way things are going on. There are many known examples of work leaving W3C to OASIS, etc. because some companies didn't like the terms. But the real damage is that the more strict the policy is, and the more rigid the process is, the less likely are people to participate. We all have jobs and employers and in most cases they control our IP and ability to participate in any such process.

People come to the IETF because this is where the knowledge is. This is where the experience is for many internet technologies. The IETF does not have the power or means to stop anyone from changing their work or proposing competing standards. What it has is the voice of a community that still matters more than many.

I have a lot of criticism for the IETF IPR process, or complete lack of meaningful protections. But I don't go around pointing fingers and make up conspiracy theories. I just talk to people, bring small and big players to the table, and try to be creative about it. And guess what, people are actually listening to what we are doing in the OWF.

If you think I am full of it, just wait a year or two and let's talk again then.

EHL

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Mar 2009 15:47:07 +0000

On Wed, 11 Mar 2009, Melinda Shore wrote:
> > I was also under the impression that a lot of RFCs are *not* "IETF
> > RFCs", since the RFC editor will publish certain types of RFCs without
> > them having gone through an IETF process.
>
> They certainly have gone through an IETF process to get published,
> whether they're a working group document or individual contribution.

April 1st RFCs are one example of non-IETF RFCs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 Mar 2009 14:00:56 -0400

--On Thursday, March 12, 2009 15:47 +0000 Tony Finch
<[email-masked]> wrote:

>> individual contribution.

So is the entire independent submission track (of which April 1
RFCs are a special case, special because they are not posted as
I-Ds first and not reviewed by the IESG).  For the rest of the
independent submission track, unless IANA assignments are
needed, the only required "IETF process" is review by the IESG
to determine whether they conflict with ongoing WG efforts.

Formally, the RFC Series has always been an independent document
series and process, predating the IETF by many years.  The IETF,
since its inception has chosen to publish several types of
documents in that series, using specific rules agreed to by the
RFC Editor and in which other groups choose to publish other
types of documents (naturally under somewhat different rules).
The IETF has never been required to use the RFC Series by any
external body and that requirement does not exist today.   If
the IETF decided to take its work and standards-track
publications elsewhere, we would presumably have some issues
with funding and organizational structure for the RFC Editor
function,  but, at least in principle, that function would not
change other than not having the IETF-produced portion of its
workload.  

Assertions that the fact that the IETF publishes standards-track
documents in that series changes the rules and conventions for
the appropriate series are interesting speculations but just
don't hold water.  

I would strongly encourage those who are participating in this
discussion to go back and reread RFCs 4844 and 4846 and, as a
non-IETF stream example, 4845.  That knowledge might help focus
this rather strange (IMO) thread a bit.  On the other hand, if
anyone participating in this discussion were to consider facts
merely an incidental inconvenience to the points they are trying
to make, I don't suppose those documents or this note will make
any difference.

      john

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 12 Mar 2009 14:52:55 -0700

John C Klensin wrote:
> So is the entire independent submission track 

Rather than having us randomly provide stray explanations about RFC basics, why 
don't we simply suggest that people who are interested in discussing the nature 
of, and concerns with, RFCs first become familiar with the considerable set of 
documentation that define and describe them, starting with:

    <http://rfc-editor.org/RFCoverview.html#streams>

d/

-- 

   Dave Crocker