IETF mission (RE: pausable explanation for the Document Series)

[Dave Crocker]

John,

JCK> Actually, unless my memory has gone _very_ bad, we have had
JCK> applicability statements as tools in the collection for a long 
JCK> time, certainly before 2026. I think they were even called that

It isn't.  We have.  They were.


JCK> that.  We haven't used them very much because it has been 
JCK> extremely difficult to get energy and focus for those efforts --

I believe that we haven't used them because it has always been difficult
to figure out what they actually should mean or how they should actually
be used. They have not had a sufficiently pragmatic, operational quality
to them.


JCK> <tirade>
JCK> The fact that these are hard to get done doesn't imply that we 
JCK> should have written them off,

(for this community, your version of a tirade is cute.)

Let me suggest that the most significant thing in your commentary, along
with some other observations that have been showing up, is that we are
all tending to believe that we have to invent all sorts of structures
and processes, often ignoring existing ones.

We should, at least, consider reviving the ones that have been ignored.
(This requires actually becoming familiar with them.)

And if we reject them, we should ask why inventing some new bit of
cleverness is likely to have any more benefit.  Why will this new thing
be any more likely to work well?


JCK> We have created a lot of confusion by also using the term
JCK> "requirements" to describe "things we really think this protocol 
JCK> ought to have in it".

or, worse, the document specifies most of the protocol, except syntax.

Perhaps the most serious difficulty with the way we use requirements
statements is that they are often written with no concern about
practicalities, and sometimes without concern about coherence for an
integrated service.  And then during protocol specification the
requirements are used to reject concerns about practicality and
coherence.


JCK> Speaking of tools we have stopped using, section 3.3 of 2026
JCK> describes requirement levels (formerly "status", see below) for 
JCK> documents -- required/ recommended/ elective/ limited use/ not 
JCK> recommended.

Again, I believe this is because we never figured out how to make them
be really meaningful.


JCK> 'standard'".  I wonder whether we might have reduced some
JCK> confusion had we preserved that particular distinction --not 
JCK> using the term "standard" at all to refer to proposed-level 
JCK> documents --in wording.

oh, you optimist, you.

d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>