Re: [art] BCP 190, draft-nottingham-for-the-users, and a generalization

John --

It's going to take a while for me to formulate my thoughts around what 
you say below. To make sure I understand the class of constraints you're 
concerned about below, can you clarify whether you think they apply to:

  * Documents like BCP 200, RFC 2804, and BCP 188?
  * Documents like BCP 9 and BCP 92?
  * Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list 
above, so I'll state it explicitly: in the general case, one person's 
important protections against a tragedy of the commons is another 
person's annoying impediment to be ignored and defeated. I get that not 
all of the above read on protocol design; but they do share the common 
feature that they've gone through the IETF consensus process (at least 
to the degree that such a process existed at the time of their 
respective publications). If we're going to carefully parse out the 
meanings of some of them as the will of the community while treating 
others as light guidelines to be ignored when they become cumbersome, 
we're going to need to agree on a pretty bright line that divides those 
categories.

/a

On 7/23/19 08:37, John C Klensin wrote:
> (copying architecture-discuss because the comment I'm about to
> make is an architectural issue and because
> draft-nottingham-for-the-users is under discussion there.)
>
>
> A late colleague, much loved by some of us, used to claim (much
> more elegantly than I can manage) that one of the reasons the
> ARPANET and then the Internet protocols had succeeded and much
> of what was seen as competitive alternatives had not, was that
> our efforts focused on pragmatic, working protocols and
> implementations.
>
> The other folks had developed a culture of formalisms, models,
> and stated design principles.  They then tried to develop
> protocols that fit into the boxes and categories of those
> formalisms, models, and design principles.    When they
> discovered that something didn't fit, they needed to either
> invent kludges or other ways of getting square pegs into round
> holes, go back and revise models and guidance before moving
> forward, or consider and make exceptions (which often required
> first figuring out how to make an exception and developing
> procedures for that).
>
> One difficulty is that the above can waste a lot of time.
> Another is that it can distort protocol design, if only because
> forcing square pegs into round holes tends to be hard on both
> the pegs and the holes.
>
> In many or most fields of application, the nature of engineering
> involves seeing and understanding a range of tradeoffs and then
> doing design work that reflects a carefully-chosen balance among
> them.  Give design elegance absolute priority over structural
> issues and buildings and bridges fall down.  IMO, we need to
> think, and keep thinking, about systems and tradeoffs.  That, in
> turn, means that statements like these that can be interpreted
> in absolute terms, even if we mostly agree with them, should be
> packaged as general guidelines and not BCPs to which everything
> done in the future is required to either conform or to try to
> figure out how to appeal to a higher authority.
>
> I'm not at all convinced that the proposal that was summarized
> an ARTAREA yesterday and that is seen as requiring an exception
> to BCP 190 is a good idea.  But I think our time would be better
> spent, and the Internet more efficiently made better, discussing
> the strengths, weaknesses, and alternatives to that idea rather
> than debating the reach and appropriateness of BCP 190 under
> various circumstances.   Long term and more generally, I think
> that suggests seeing BCP 190 not as a particular set of
> principles and rules but as an example of something we don't
> want to do to ourselves again as a BCP (or as something that
> gets enough of an IAB stamp of approval that people will later
> argue MUST (or SHOULD) be conformed to.  Again, restated as
> general guidance with the assumption that there will be
> exceptions and cases not considered, I don't have much of a
> problem.    If that shoe fits  draft-nottingham-for-the-users,
> so be it.
>
>     john
>
> p.s. I don't mean to pick on Mark here.   While these two
> documents coming up at the same time was handy, I think the
> problem is general and that there are far worse examples
> (examples of which he is not an author) than either of them.
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art