g'day,



Keith Moore wrote:

> 

> > One would be hard-pressed to inspect the author-list of

> > draft-cerpa-necp-02.txt, the work of the associated companies, and the

> > clear need for optimizations of application performance, and then deem this

> > document not relevant.

> 

> I'm not hard-pressed to do this at all.  In fact I find it quite easy,

> because I don't care who the authors work for.

> 

> IMHO, we should base not publication decisions on the authors' employers.

> We should base them on technical merit.



Okay, I did some digging. Here are a few relevant excerpts from RFC
2026:



...

   The RFC series of documents on networking began in 1969 as part of

   the original ARPA wide-area networking (ARPANET) project (see

   Appendix A for glossary of acronyms).  RFCs cover a wide range of

   topics in addition to Internet Standards, from early discussion of

   new research concepts to status memos about the Internet. 

...

   Not all specifications of protocols or services for the Internet

   should or will become Internet Standards or BCPs.  Such non-standards

   track specifications are not subject to the rules for Internet

   standardization.  Non-standards track specifications may be published

   directly as "Experimental" or "Informational" RFCs at the discretion

   of the RFC Editor in consultation with the IESG (see section 4.2).

...

      ********************************************************

      *                                                      *

      *   It is important to remember that not all RFCs      *

      *   are standards track documents, and that not all    *

      *   standards track documents reach the level of       *

      *   Internet Standard. In the same way, not all RFCs   *

      *   which describe current practices have been given   *

      *   the review and approval to become BCPs. See        *

      *   RFC-1796 [6] for further information.              *

      *                                                      *

      ********************************************************

...



4.2.1  Experimental



   The "Experimental" designation typically denotes a specification that

   is part of some research or development effort.  Such a specification

   is published for the general information of the Internet technical

   community and as an archival record of the work, subject only to

   editorial considerations and to verification that there has been

   adequate coordination with the standards process (see below).  An

   Experimental specification may be the output of an organized Internet

   research effort (e.g., a Research Group of the IRTF), an IETF Working

   Group, or it may be an individual contribution.

...



4.2.2  Informational



   An "Informational" specification is published for the general

   information of the Internet community, and does not represent an

   Internet community consensus or recommendation.  The Informational

   designation is intended to provide for the timely publication of a

   very broad range of responsible informational documents from many

   sources, subject only to editorial considerations and to verification

   that there has been adequate coordination with the standards process

   (see section 4.2.3).



   Specifications that have been prepared outside of the Internet

   community and are not incorporated into the Internet Standards

   Process by any of the provisions of section 10 may be published as

   Informational RFCs, with the permission of the owner and the

   concurrence of the RFC Editor.

...



   If (a) the IESG recommends that the document be brought within the

   IETF and progressed within the IETF context, but the author declines

   to do so, or (b) the IESG considers that the document proposes

   something that conflicts with, or is actually inimical to, an

   established IETF effort, the document may still be published as an

   Experimental or Informational RFC.  In these cases, however, the IESG

   may insert appropriate "disclaimer" text into the RFC either in or

   immediately following the "Status of this Memo" section in order to

   make the circumstances of its publication clear to readers.





Seems pretty clear to me. Given that one of the roles of the IETF is

"Providing a forum for the exchange of information within the Internet

community between vendors, users, researchers, agency contractors and

network managers" (ref: RFC 1718), it would seem appropriate to publish

material from vendors that is finding widespread use, even if it

violates some individuals' personal view of the how the Internet should

be built.





> The trade press is quite good at fawning over vendors' products;

> I don't think IETF needs to take on that role.



You seem quite afraid of the IETF being hijacked by vendors' marketing
people, but I submit you are denying a documented role of the IETF to be
a clearing house for information in the process. If you want the
appropriate words of RFC 22026 and 1718 deleted that you take the
appropriate steps to initiate the change, but I suggest that meanwhile
you shouldn't be denying the documented evidence for such a role within
the IETF.



                                        - peterd




-- 
----------------------------------------------------------------------
Peter Deutsch                     work email:  [EMAIL PROTECTED]
Technical Leader
Content Services Business Unit       private: 
[EMAIL PROTECTED]
Cisco Systems                           or  :  [EMAIL PROTECTED]

   A specification that has been superseded by a more recent

   specification or is for any other reason considered to be obsolete is

   assigned to the "Historic" level.  (Purists have suggested that the

   word should be "Historical"; however, at this point the use of

   "Historic" is historical.)
----------------------------------------------------------------------

Reply via email to