Subject: Re: ECM WG last call for draft-floyd-cong-01.txt as BCP

From: Scott Bradner <[email-masked]>
Date: Sat, 11 Mar 2000 21:10:34 -0500 (EST)

> I view them differently - they are closer to statements of current IETF
> policies & recommendations.  The "current" is because policy/recommendations
> can change, not because we don't expect things to change any time soon.  

this is what I have in mind when talking about BCPs (I'd just as soon
think that BCP does not imply a quick change because I'd just as not
open up rfc2026 for a while :_) )

Scott

---

From: John Leslie <[email-masked]>
Date: Sat, 11 Mar 2000 23:17:52 -0500

(I've restored context -- note the ]'s)

On Sat, Mar 11, 2000 at 09:10:34PM -0500, Scott Bradner wrote:
] Vern Paxson <[email-masked]> wrote:
]] John Leslie <[email-masked]> wrote:
]] 
]]> BCPs, in my experience, have been a temporary terminal point: we
]]> know a problem exists; we don't feel any progress is imminent; and
]]> we want to publish how we deal with it, because that way seems "good
]]> enough".
>> policies & recommendations. 

   Sad... to think the IESG has come to view it as its job to set "policy"
at each meeting. :^(

>> The "current" is because policy/recommendations can change, not because
>> we don't expect things to change any time soon.  

   Sad... to think that policies should be expected to change on short
notice. :^(

> open up rfc2026 for a while :_) )

   I'm not sure I understand Scott's point. RFC 2026 was written in 1996,
and I don't know anybody who wants to change it. The relevant part would
seem to be:

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

   (which suggests to me substantially more than issuing a "Last-Call"
and a quick IESG vote.)
   
]    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.

   Doesn't this suggest that BCPs should include guidelines for humans,
rather than algorithms for computers? I believe our charter is closer
to the latter.

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

   I still maintain that the document cited is written in the style of
an Informational RFC (and fulfils that function well).

--
John Leslie <[email-masked]>