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

From: <[email-masked]>
Date: Fri, 6 Jun 2003 07:56:29 +0300

Hi Charles,

> I also wholeheartedly support the inclusion of an applicability
> statement whenever it makes sense.  However, I also suggest that
> the protocol SHOULD (within engineering discretion) not intentionally
> restrict its applcability to the situations delineated in the
> applicability statement.
> 
> I would restate Postel's maxim:
> 
> Be conservative in the claimed applicability, but generous
> in the potential applicability.

What I am concerned about is there seems to be a movement to
make a super-PS, one which would be the equavalent of a DS
& have no bugs.  I am not sure of the feasibility of this,
but I have noticed that simple protocol documents are getting
overloaded with a lot of applicability info, deployment concerns,
best practices and implementation guides.  Somehow, I think
overloading a single document with this info, is not a 
reciepe for success.

John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jun 2003 13:50:22 +0200

> overloading a single document with this info, is not a

In any case, since we don't actually use the complexity we
already have (3 grades of standard), the need is clearly to
*simplify* the document scheme, not to complicate it. My thinking
is getting more radical the longer this discussion continues. Let's
think seriously about

 Problem: the 3 step standards track is largely fictional

and possible solutions along the lines of

 Solution: let's scrap it and have all "standards" RFCs as a single level
 (with recycling in grade for corrections/updates).

   Brian

---

From: Ralph Droms <[email-masked]>
Date: Fri, 06 Jun 2003 08:08:09 -0400

Regarding Brian's call for radical thinking...

Is the problem:

   the 3 step standards track is largely fictional

the root problem or just a symptom?  

I think it's just a symptom of a mismatch among industry
uses for IETF standards, WG processes and IESG goals.

The current *usage* of the standards track effectively
has a single hurdle at PS.  I suggest we need to devise
a process and set of hurdles that include some intermediate
states that are not well-defined in the current usage
of the standards track.

One of the important states that is missing today is

   stable specification used for prototyping

My recent experience with specifications in the dhc WG
has been that "running (prototype) code" trumps
(potentially ad infinitum) speculative discussion about
whether the protocol is correct and completely
specified.  

The design problem, of course, is devising the right
document classifications and process to strike a balance
among nimbleness (getting to a stable specification
quickly), correctness and allowing for changes after
the prototypes have been developed (avoiding the
"we've deployed the prototype and now we can't change
the protocol" problem)...

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Fri, 6 Jun 2003 09:44:50 -0400

> & have no bugs. 

I haven't seen any evidence of such a movement, and that's certainly not what
I've proposed.  Surely nobody thinks it's feasible to get rid of all bugs.
What I've proposed is that we need to figure out what the criteria should
be for "ready for deployment", and that these are probably slightly higher
than those currently in place for PS (but IMHO lower than those required for
DS).  "ready for deployment" doesn't mean "bug-free", but it does seem to
imply a certain amount of diligence in looking for bugs, and at least
minimal implementation and testing.

> I have noticed that simple protocol documents are getting overloaded with a
> lot of applicability info, deployment concerns, best practices, and
> implementation guides.

I think you exaggerate when you say "overloaded".  But these most certainly do
belong in a protocol standard, and there's some experience that says that
they're
more likely to be ignored if placed in a separate document.  (though it might
help if our document numbering scheme made it easier to find related
documents.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 6 Jun 2003 10:06:46 -0400

> *simplify* the document scheme, not to complicate it. 

the need is clearly to change the set of maturity levels.  
whether this results in fewer levels is not yet clear.

---

From: Keith Moore <[email-masked]>
Date: Fri, 6 Jun 2003 10:14:30 -0400

>    stable specification used for prototyping

agree, though you might qualify "stable" to mean
"during the prototyping period".  it can be extremely
useful to prototype subsets of a protocol even though
those subsets are not complete enough to ship.  and
what's the point of prototyping if not to allow for
the possibility of changing something?

(but since this is the problem statement working group, isn't
it enough to say for now that there's a mismatch between our
document maturity levels and both industry expectation and IETF
energies?)

---

From: Ralph Droms <[email-masked]>
Date: Fri, 06 Jun 2003 10:30:14 -0400

Regarding "problem statement" versus "proposed
solution" ... I was careful to refer to a
"missing state" rather than a missing maturity
level or process.  The problem is that we need
a way to do prototyping, requiring some
stable-during-the-prototyping document, that
does not then result in deployment of implementations
of a buggy protocol.

- Ralph

---

From: Eric Rosen <[email-masked]>
Date: Fri, 06 Jun 2003 10:58:01 -0400

Perhaps we  need to  understand better  just what problem  we are  trying to
solve by revising the categorization of standards. 

I'd make two observations: 

1. Nobody  cares  whether  the  IETF  says  that a  protocol  is  ready  for
   deployment or  not.  Service providers, vendors,  enterprises, etc., will
   decide this for themselves. 

   By "nobody", I mean "nobody who is  in a position to decide whether to do
   any large scale deployments".  In the old world of the ITU-T people don't
   deploy  until the  standards  process  is finished,  which  leads to  (a)
   bizarre standards  and (b) slow progress.   That may have  been okay when
   telecom providers were monopolies, but  it is not okay in the competitive
   environment of today.

2. People  do care  about whether  the protocol  has a  public specification
   which  is sufficiently detailed  so as  to enable  interoperability among
   multiple independent  implementations.  However, they will  not wait (nor
   should they) for such a specification before deployment.

Based on these observations, there  has arisen a significant constituency in
the IETF  (though not seen much on  this list) which believes  that the only
proper  function  of  the  IETF  is  to  publish  specifications  which  are
multi-vendor interoperable.  Members of  this constituency see no benefit at
all for IESG  review.  Members of this constituency  would also be overjoyed
if  all  their   specs  could  just  get  published   as  "Experimental"  or
"Informational", and once the specs  get published, they have no interest in
moving them further along in the process.

Most people  on this list seem  to think that there  is a value  in having a
category  of  "standard"  which  means  something  more  than  "multi-vendor
interoperable."  But I  don't think there is a clear  consensus on just what
we want that to mean, and that's one of our big problems. 

Some possible considerations are: 

- correctly achieves the function which it is intended to achieve
- adequately address scalability and security considerations in the intended
  scope of applicability
- adequately (though not excessively) flexible 
- not a lot more complicated than it needs to be
- can be reasonably defended against alternatives
- specification is competently and professionally done
- impact on other areas has been addressed
- there exists significant interest in deploying this

etc. 

To  me, it makes  sense to  have a  standards category  which says  that the
specification is not merely adequate  for interoperability, but also that it
has been judged against these other considerations.

Considerations often cited which I don't agree with: 

- must not be intended for uses which violate my personal values
- must not  be intended for uses which  violate my idea of  how the Internet
  should be used
- must not be intended for uses which allow Service Providers to add value
- must not violate some alleged philosophical principle articulated 25 years
  ago 
- must  not  make  it  more  difficult  to  write  multi-party  peer-to-peer
  applications
- must have the highest conceivable level of security
- guaranteed bug-free

Based on the considerations I think are important, I don't understand why we
need  more than one  category of  standard, so  I would  tend to  agree with
Brian: "let's scrap it all and  have a single level (with recycling in grade
for corrections/updates)."

---

From: Keith Moore <[email-masked]>
Date: Fri, 6 Jun 2003 11:14:22 -0400

On Fri, 06 Jun 2003 10:58:01 -0400
Eric Rosen <[email-masked]> wrote:

> there  has arisen a significant constituency in
> multi-vendor interoperable. 

those people are naive.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Jun 2003 16:05:52 -0700

Eric,

ER> Most people  on this list seem  to think that there  is a value in having a
ER> category  of  "standard"  which  means  something  more  than  "multi-vendor
ER> interoperable."

It occurs to me that you may have backed into exactly the real
disparity.

Historically, the goal of IETF work was to produce specifications that
were KNOWN to be interoperable.

In recent years, we stopped worrying about the reality of
interoperability and settled for "looks goods after a static review of
the document". And we let the rest of the world decide what to do with
the document after that.

So, for one thing, we have stopped very seriously worrying about running
code, or actual use, or any such mundane concern.

(and no, that's not an absolute, but I believe it does characterize the
change in IETF culture.)

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: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Jun 2003 15:04:38 +0200

Eric Rosen wrote:
...
> Considerations often cited which I don't agree with: 

It's a bit hard to separate the polemic from the rational in this

> - must not be intended for uses which violate my personal values

That really doesn't seem to me to be a factor. As we saw with RFC 1984 
and RFC 2804, to take two examples that may be relevant to your 
underlying point, when there is a clear majority view among the 
individual engineers who make up the IETF, the IETF may decide that 
certain things are inappropriate topics for standardization in the IETF.

> - must not  be intended for uses which  violate my idea of  how the Internet

Same response.

> - must not be intended for uses which allow Service Providers to add value

There is a principle, which I think has been articulated often as a shared
value in the IETF, that we shouldn't standardize things that harm the
Internet as a whole, or that destroy global connectivity and access. It may
well be that this principle is sometimes in conflict with tools that might
serve short-term commercial interests of SPs. I would indeed hope that
the IETF would decline to standardize such things. But your version
is caricature.

> - must not violate some alleged philosophical principle articulated 25 years

Let's just pretend you didn't write "alleged" and "philosophical". There
are a bunch of engineering principles that *were* articulated between
about 1974 and 1985 that are objectively behind the Internet's success
(compared say to SNA, DECnet, and OSI). Some them were collected in
RFC 1958. The basic physics of packet switching hasn't actually changed 
much since 1969. So if you think that there have been changes that 
invalidate some of those principles, please write the Internet-Draft 
explaining this.

> - must  not  make  it  more  difficult  to  write  multi-party  peer-to-peer

Yes, that's a very valid technical objection to certain things. The future
of e-business certainly requires multi-party peer-to-peer connectivity,
so I'd say there's a few hundred billion dollars of revenue riding on
this one.

> - must have the highest conceivable level of security

Caricature. "Must not have sloppy security" is more like it.

> - guaranteed bug-free

Caricature, but indeed any pretence that we can have bug-free specs
first time is illusory.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Jun 2003 07:36:22 -0400

--On Friday, 06 June, 2003 13:50 +0200 Brian E Carpenter 
<[email-masked]> wrote:

> *simplify* the document scheme, not to complicate it. My
> thinking is getting more radical the longer this discussion
> continues. Let's think seriously about
>
>  Solution: let's scrap it and have all "standards" RFCs as a
> single level  (with recycling in grade for
> corrections/updates).

Sigh.  I wondered how long it would take us to get there.

Several years ago, when it became clear that the efforts (and 
investment) on OSI were going nowhere, and that TCP/IP was 
taking over, many of the "traditional" standards bodies went 
into a huge excursion of "future standards planning" in which 
they tried to map out a future in which users and industry 
didn't automatically come to them every time a standards issue 
arose.  From their perspective, that (and bodies like the IETF) 
were problems that needed fixing.

Now there was a subtext in some of those concerns, which might 
have been stated as "how do we professional standardizers, 
process experts, and generalized go-ers (thanks, Marshall) who 
haven't done real engineering and design for years (if ever) 
keep our nice jobs, frequent flyer miles, and fine lunches and 
dinners?"  but, regardless of the motivation, the problem 
remained: what were groups like the IETF doing that they needed 
to imitate, co-opt, or defeat?

There were several answers:

(1) We didn't standardize fantasies about where the industry was 
likely to go, or where we wanted it to go.  No "anticipatory 
standards" here.  Documents didn't advance to full standard, or 
even draft standard, unless there was solid implementation 
experience.

(2) We didn't have a mandatory five-year (or other) review cycle 
that led to permanent WGs dedicated to each [group of] 
standards, provided a full-employment situation for WG chairs, 
and virtually guaranteed second-system effects (while the 
initial development WG often contained solid engineering 
expertise and was usually in touch with real customer and 
product requirements, and the first review cycle might contain 
some of those people in order to fix bugs that had been 
discovered, by the time of the second review (third time around) 
sponsoring companies had almost always pulled out the useful 
designers, replacing them with people whose fantasies about 
improvements usually exceeded their experience and knowledge).

(3) We were reluctant to simply declare an old standard obsolete 
and replace it.   Instead, we worried a great deal about 
compatibility and interoperability between old versions and new 
ones.   And we didn't "withdraw" the old documents from the 
marketplace, making copies of it essentially unavailable.

(4) We didn't try to support the standards process, or its 
bureaucracy, by either selling standards (and tight control over 
copyrights to make that feasible) or extracting high 
participation, "membership", or "service" fees from participants.

(5) Partially as the result of (4), we enabled and encouraged 
participation by interested and dedicated individuals and also 
from academics and researchers (not just corporations, 
government bodies, and institutional IT departments).

(6) Our key participants were still rooted in products -- 
developing code, determining requirements, doing leading-edge 
research in the relevant technologies -- rather than being 
full-time standardizers or process experts.

The "optimists" within those traditional standards believed that 
all of the above were just the result of our lack of 
organizational maturity.  They were convinced that, as age, 
scale, and a sense of responsibility toward the marketplace 
caught up with us, much of the above would disappear and we 
would turn into "them".

I thought they were wrong.   I'm beginning to wonder.  Note, for 
example:

(i) We have apparently succeeded in turning the IESG into a full 
time job.  Some of the members are essentially lent to us for a 
while from the product-rooted jobs identified in (6) or are 
still trying to do IESG along with day jobs.   But we are, at 
best, on a slippery slope.

(ii) More and more of our proposed standards are approved at "we 
generally think this is a good idea" phase, rather than on the 
basis of solid experience along at least some dimensions.  That 
is ok, because we still have Draft and Full standard levels... 
whoops, we are now talking about dropping those (note that this 
has nothing to do with whether or not those two grades should be 
combined).

(iii) We are talking about semi-permanent "maintenance WGs".  It 
may well be a good idea, and better than any of the 
alternatives, but it takes us away from the "WGs get formed 
around a specific function, do their work, and then dissolve" 
model... and we had best be careful what we wish for.

(iv) Meeting fees have reached a level we would have considered 
inconceivable a decade ago, and we have considered shifting more 
authority and responsibility to the Secretariat and other 
IETF-paid professionals as a means of reducing load on the IESG 
and/or WG Chairs and Editors, etc.

Hmm...

    john

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 12 Jun 2003 15:26:56 -0700 (PDT)

On Tue, 10 Jun 2003, John C Klensin wrote:
> [ ... ] what were groups like the IETF doing that they needed 

This is (or was) a good thing about the IETF, and we should try
to keep it (or reinstate it).  A two-grade process (Experimental
and Standard) along the lines I proposed a few days ago, viz:

% - specs start out in life as Experimental, recycling there
% [as] necessary until
%
% - there are no known problems and at least two interoperable
% implementations, at which point they would be eligible for
% elevation to Standard (and could stay there on subsequent
% revisions, if the changes were not "too drastic")

would allow us to do that, and at least has the possibility of
being better geared to reality than our current three-grade
system.

> improvements usually exceeded their experience and knowledge).

Hmm.  I've often thought that the lack of mandatory review for
standards (especially full standards) is a big PROBLEM in the
way the IETF works.  It hurts in several ways:

- we don't update specs to remove things that are clearly
obsolete.  An excellent example is the TOS stuff that peppers
RFC 791, RFC 1112, and RFC 1812 ... all this was officially
retired when the DiffServ stuff was launched.  The specs
should be brought up-to-date to match the reality.

- we don't do maintenance revisions that are probably
necessary.  An example of this is the SMIv2 specs.  We
found some ambiguities and errata in the SMIv2 RFCs in
the course of developing "Guidelines for MIB Authors and
Reviewers."  In addition, there are some known omissions
(i.e., lack of 64-bit data types) that we are using
kludges to work around.  If we want this stuff to last
for a while, a maintenance revision to fix the bugs and
small omissions would, I think, be in order.

- we don't retire obsolete stuff as soon as we should.
RFC 1643 is an example of this.

In fairness, these problems are not entirely due to the
lack of mandatory periodic review;  I think they are also
attributable in part to a reluctance to make small changes
to an Internet Standard, since it forces a recycling back
to Proposed Standard.  This can hit at any stage of the
process ... if I remember correctly, that was one reason
why adding 64-bit data types to SMIv2 was ruled out-of-scope
in the 1998-1999 time frame when the specs were being updated
for advancement from Draft Standard to (full) Standard.

> marketplace, making copies of it essentially unavailable.

Good point ... in adopting a proposal such as the two-grade
proposal above, changes that break backward compatibility
in a significant way should be deemed "too drastic" to permit
recycling in grade.  But the current doctrine of permitting
nothing new at all is counterproductive, IMHO.

//cmh