Re: Last Call: Administratively Scoped Multicast to BCP

[Thomas Narten <narten at raleigh.ibm.com>]

> The first example of a BCP specifying an administrative procedure
> (and something that was not a current practice before its publication)
> is BCP 1, RFC 1818, which defined the term.

The 1818 definition has been superseded by 2026.  I've included the
relevent text for everyone's reading pleasure, as there still seems to
be confusion on exactly what a BCP is. There is certainly no
requirement that a practice be "current" to be eligible to be a
BCP. Consensus is what is required.

5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

   Historically Internet standards have generally been concerned with
   the technical specifications for hardware and software required for
   computer communication across interconnected networks.  However,
   since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.
   While these guidelines are generally different in scope and style
   from protocol standards, their establishment needs a similar process
   for consensus building.

   While it is recognized that entities such as the IAB and IESG are
   composed of individuals who may participate, as individuals, in the
   technical work of the IETF, it is also recognized that the entities
   themselves have an existence as leaders in the community.  As leaders
   in the Internet technical community, these entities should have an
   outlet to propose ideas to stimulate work in a particular area, to
   raise the community's sensitivity to a certain issue, to make a
   statement of architectural principle, or to communicate their
   thoughts on other matters.  The BCP subseries creates a smoothly
   structured way for these management entities to insert proposals into
   the consensus-building machinery of the IETF while gauging the
   community's view of that issue.

   Finally, the BCP series may be used to document the operation of the
   IETF itself.  For example, this document defines the IETF Standards
   Process and is published as a BCP.

5.1 BCP Review Process

   Unlike standards-track documents, the mechanisms described in BCPs
   are not well suited to the phased roll-in nature of the three stage
   standards track and instead generally only make sense for full and
   immediate instantiation.

   The BCP process is similar to that for proposed standards.  The BCP
   is submitted to the IESG for review, (see section 6.1.1) and the
   existing review process applies, including a Last-Call on the IETF
   Announce mailing list.  However, once the IESG has approved the
   document, the process ends and the document is published.  The
   resulting document is viewed as having the technical approval of the
   IETF.

   Specifically, a document to be considered for the status of BCP must
   undergo the procedures outlined in sections 6.1, and 6.4 of this
   document. The BCP process may be appealed according to the procedures
   in section 6.5.

   Because BCPs are meant to express community consensus but are arrived
   at more quickly than standards, BCPs require particular care.
   Specifically, BCPs should not be viewed simply as stronger
   Informational RFCs, but rather should be viewed as documents suitable
   for a content different from Informational RFCs.

   A specification, or group of specifications, that has, or have been
   approved as a BCP is assigned a number in the BCP series while
   retaining its RFC number(s).








Bradner                  Best Current Practice                 [Page 17]

RFC 2026               Internet Standards Process           October 1996