Subject: RE: pausable explanation for the Document Series

From: <[email-masked]>
Date: Thu, 5 Jun 2003 11:36:04 +0300

Hi Harald,

> > I've always assumed that industry does not use DS or FS simply because
> > the IETF does not produce them in any great number.  The IETF doesn't
> > seem to produce them because WGs are, in general, charted to make
> > PSs; after which, they try to shut down.  There is very little incentive
> > in the IETF progress documents.  Industry, being industry, takes what
> > they get & runs with it.
> >
> > I'm not sure how many of the proposals discussed would impact this
> > situation in any meaningful way.
> 
> at least two try to:
> 
> Brian's DS/Full merger

Actually, I'm not sure how Brian's proposal fits into the above 
picture, since PS seems to be the default level for most work
done in the IETF.  Without internal motiviation to progress the
work, I'm not sure it makes a difference.

> <shameless plug>
> Maintenance Teams
> </shameless plug>

I didn't think about your proposal in these terms, but the more 
I do, the more I like it.  It is, basically, the IETF taking
care of its own messes, which is a good thing.

> but industry running on PS is not a core problem, I think.

I agree - mostly because it is outside of our ability to control.

> The more-core problem is industry running on protocols with design flaws 
> and protocol bugs, which cannot be fixed because of the installed base.

Depends upon how you look at things.  I would say that the more-core
problem is that our quality control may be less than ideal.  As the IETF
is not a protocol enforcement agency, what the industry does with
what we make is beyond our control, in my opinion.

> If PS was perfect, this would not be a serious problem. But 
> it isn't so.

This touches on the relevant issue.  Should PS be perfect? At what
level do we raise (or lower) the bar?  What can we do about it?  
One possibility would be that we make sure that PS documents are
as perfect as possible (raise the bar).  Another could be to
require some sort of best practices document for most major PS
documents (which would capture operational issues, etc).  Another
could be your Maintenance Team idea, especially if it is coupled
with an object that captures all of the relevant RFCs, drafts
in progress, bug reports, etc.  I also think that if we go the
route of Maintenence Teams, perhaps the object could also
preserve any issue lists created during WG / IETF last call.

John

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 05 Jun 2003 12:33:55 +0200

> what we make is beyond our control, in my opinion.

actually this comes back to the IETF mission statement thing....

if the mission of the IETF is to "make the Internet work", with our 
particular task in pursuit of that mission being to "make high quality, 
timely standards for the Internet", then flaws in the standards that the 
industry runs on are signs that we haven't achieved our mission.

I don't think we can assert "control", in the sense of "I decide, it 
happens" - if I asserted that I was in control of the IETF, I'd be as silly 
as if the IETF claimed that it was in control of the Internet.

But I do have influence over what the IETF does (and so do you), and the 
IETF does have influence over what the industry does.

Might be semantic quibbling .... then again, it might actually matter when 
we decide what to do.

> documents (which would capture operational issues, etc).

RFC 2026 invented the term "applicability statements" - that's a term that 
seems to have fallen by the wayside......

>  Another

The "protocol, its current state and history book" site? Seems to make 
sense to me..... much of ancient history is actually preserved in various 
archives, but it can be VERY hard to find......

Nice thought!

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Jun 2003 08:01:11 -0400

--On Thursday, 05 June, 2003 12:33 +0200 Harald Tveit Alvestrand 
<[email-masked]> wrote:

>> Depends upon how you look at things.  I would say that the
>> more-core problem is that our quality control may be less
>> than ideal.  As the IETF is not a protocol enforcement
>> agency, what the industry does with what we make is beyond
>> our control, in my opinion.
>
> if the mission of the IETF is to "make the Internet work",
> with our particular task in pursuit of that mission being to
> "make high quality, timely standards for the Internet", then
> flaws in the standards that the industry runs on are signs
> that we haven't achieved our mission.
>...
> RFC 2026 invented the term "applicability statements" - that's
> a term that seems to have fallen by the wayside......

Actually, unless my memory has gone _very_ bad, we have had 
applicability statements as tools in the collection for a long 
time, certainly before 2026.  I think they were even called 
that.  We haven't used them very much because it has been 
extremely difficult to get energy and focus for those efforts -- 
they are hard to do, and rarely as rewarding as developing a 
technology standard.  Note that RFC 1122 and 1123 are definitely 
AS documents, as is RFC 1812.  If you go through the RFC list 
looking for the word "requirements", you will find it in several 
other places as the term is used by an AS in the 2026 sense.

The term "applicability statement" appears in RFC 2000 (and 
probably earlier, I haven't had time to go back through that 
thread).

<tirade>
The fact that these are hard to get done doesn't imply that we 
should have written them off, which we essentially have done... 
except by accident, when we call them something else.

We have created a lot of confusion by also using the term 
"requirements" to describe "things we really think this protocol 
ought to have in it".  We also devalued ASs by claiming, of 
late, that attempts at ASs must be published only as 
Informational, and then telling anyone who will listen that 
Informational documents don't count, despite the fact that 2026 
explicitly identifies them with standards track maturity levels. 
That doctrine has been imposed, and dropped, more or less at the 
convenience (I'm tempted to say "whim") of the IESG.  For 
example, using the definitions of 2026, RFC 3454 meets the 
criteria for an AS: it is a profile of an external standard that 
specifies how to use parts of that standard in the Internet and 
in other IETF protocols.  And it is definitely standards-track, 
but the term AS was never, as far as I know, used during its 
development or approval process.

Speaking of tools we have stopped using, section 3.3 of 2026 
describes requirement levels (formerly "status", see below) for 
documents -- required/ recommended/ elective/ limited use/ not 
recommended.   Those statements, or ones similar to them, should 
be (or should have been) much more important tools for vendors 
and others in determining what documents to use than the 
orthogonal standards-track maturity levels.  Before we dropped 
them --about the same time, if I recall, that we dropped the 
notion of conformity clauses in standards-track documents -- 
they appeared regularly and were attached to _every_ 
protocol-specifying RFC.   See 1083 for examples.

</tirade>

Incidentally, reading RFC 1083, especially section 2, can be 
very illuminating with regard to where some of 2026 ultimately 
came from.  Interestingly, it uses "proposed protocol", and not 
"proposed standard".   The term "standard" is introduced only at 
"draft", as in "draft protocol standard".   And it is very clear 
about what "draft" means in the context of the discussions 
recently on this list: "[This] draft standard state is 
essentially a warning to the community that unless an objection 
is raised or a flaw is found this protocol will become a 
'standard'".  I wonder whether we might have reduced some 
confusion had we preserved that particular distinction --not 
using the term "standard" at all to refer to proposed-level 
documents --in wording.

 regards,
    john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 05 Jun 2003 14:48:25 +0200

--On torsdag, juni 05, 2003 08:01:11 -0400 John C Klensin 
<[email-masked]> wrote:

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

I've been duly berated for the fallibility of my institutional memory. The 
AS concept is far older than 2026.

Apologies.

                Harald

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Jun 2003 07:58:59 -0700

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:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Keith Moore <[email-masked]>
Date: Thu, 5 Jun 2003 11:06:55 -0400

> be used. 

perhaps more generally - there isn't such an obvious pattern to them, either
for what they look like or how they are created, so they are mostly off
people's radar.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Jun 2003 11:13:50 -0400

> (This requires actually becoming familiar with them.)

In reading some of the recent messages I think it's become
clear, at least to me, that in some cases the "problems"
we're having aren't procedural/policy problems but rather
problems in how we're implementing established procedure and
policy.  It may be legitimate to ask if a bad implementation
of a policy is because the policy can't be implemented well,
though.

Melinda

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 5 Jun 2003 12:12:30 -0500

Ummm... this looks like another self-inflicted wound - in my
understanding of the plan, full Standard would be common,
and STDs can contain multiple RFCs, so that would be more
common, and an AS could easily be attached to a STD, so
ASes would be more easily visible.

But we run the Internet on PSes, don't use STDs in common
conversation, and have no way to tie ASes to PSes in a
visible way.

I remember, a number of years ago, carefully understanding
ASes in 2026 and then deciding that we apparently pay little
or no attention to the notion, and forgetting everything I'd
read about them.

("what OTHER problems have we already solved once?")

Spencer

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, June 05, 2003 10:06 AM
Subject: Re: IETF mission (RE: pausable explanation for the Document Series)

---

From: Scott W Brim <[email-masked]>
Date: Thu, 5 Jun 2003 13:36:06 -0400

> requirements are used to reject concerns about practicality and

How do you measure practicality of a requirement without assuming the
solution?  The reason we (occasionally) have requirements documents is
to get everyone to agree on what the problem is.  If someone says "my
customers require this", what are you going to do?  The answer is to use
requirements docs to define the working group before trying to define
the solution.  That is, if someone thinks the requirements are
impractical or not coherent, you have clear evidence that the WG should
be focused or split.