Subject: Summary status of change efforts - Updated Web page

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 16 Jan 2004 22:53:47 -0800

I've attempted to update my summary of "where everything is" and placed it 
on http://www.ietf.org/u/ietfchair/change-status.html

Because a cron job has to run before it's visible, it may be late in 
arriving - if the date at the top says "January 13", it's the new version.

A pre-production copy is on 
http://www.alvestrand.no/ietf/chair/change-status.html if anyone's in a 
hurry.

Comments welcome - but don't expect a quick response from me; I'll be 
(mostly) off the net next week....

                 Harald

---

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Jan 2004 14:26:25 +0200 (EET)

Hello all,

Sorry for opening this obvious can of worms (well, I think it has been
opened a number of times, so the worms are probably already gone
now..), but when considering how the IETF needs to change, it's
obvious that we'll first (unless we just stick to the relatively
"safe" changes, like improving review, enhancing the tools,
streamlining the process, etc.) have get consensus on what the IETF
should be doing in the first place.

From the URL (and the material it references):

http://www.alvestrand.no/ietf/chair/change-status.html

.. I'll quote some important pieces (hopefully) not too much out of 
context:

===
The common purpose that brings the IETF together is that "The Internet 
must work". 
===
 - I believe that's a shared purpose; of course, different people have 
different things in mind when they think about what constitutes
"Internet" and "work" though.

===
A large part of making the Internet work is the job of others, and NOT 
IETF business - because others do it better. 
This includes: 

 - Deploying networks. ISPs do that. 
 - Building products. Vendors do that. 
 - Regulating the ways in which the Internet can be used. Governments 
do that (and ICANN tries to). 
===
 - These are so overly broad statements that they're close to unusable
UNLESS you believe IETF is just a rubber-stamping standards
organization.  For example, what constitutes "deploying networks"?  
IETF certainly shouldn't be go digging fibers, or give advice on how
to dig fibers.

But as the vast evidence makes it clear, most ISPs do a very lousy job
of deploying networks *properly*, causing harm to the Internet as a
whole.  Wouldn't it be somewhat in the IETF's business to try to give
advice (using BCP and Info documents) how to do it better?  

I guess one could argue against this, with "well, then why don't the
users pick their competitors?" -- but the point is that many networks
aren't really that bad on the user of *that* network, but for the
Internet as a whole.  It seems pretty clear that "darwinism" doesn't
help, and the stakes ("the commons") are too high to ignore these
issues.

Similarly, "building products" is vague, and may become problematic
especially if one believes the IETF (however that decision could be
reached is another can of worms entirely) has the power to say "No, we
don't want to standardize FOO" or "No, we don't want to standardize
the means to do BAR using the approach FOO".  Then the vendor could
argue it's not the IETF's business to tell how it should build it's
products.  Similarly, this "gray area" is often invaded when the
specifications state which knobs, toggles or features MUST/SHOULD be
implemented -- isn't this also telling the vendors how to build
products? (Of course, there is a fine line with actually "building
products" and "documenting how one could build a product (if it was to
be standards-compliant)".)

"Regulating the Internet" is also not problem-free.  If the IETF
decides not to standarize or publish something which is considered to
be a Bad Thing (e.g., NAT for IPv6, Wiretapping mechanisms, VOIP
Backdoors, etc.etc.) -- couldn't one argue that the IETF is basically
regulating the Internet by some means?  Naturally, the IETF has no
power outside it's own "jurisdiction" (i.e., publishing documents, and
to an extent, overseeing the administration of number spaces), so the
IETF can't (and shouldn't) disallow someone from doing something which
may be a bad idea anyway -- just it won't give its "blessing"  for
doing so.  But still, it seems the IETF is trying to (gently)  guide
the Internet around the things that seem like really bad ideas.
 
===
"The purpose of the IETF is to create high quality, relevant, and 
timely standards for the Internet."

Note that this clearly positions the IETF primarily as a standards 
development organization. There are other activities in the IETF; but 
if the IETF does not do its core mission, all else will quickly fade.

[...]

Supporting missions
[...]

The IETF has also had a strong operational component, with a tight 
bond, and hence coordination, between protocol developers and network 
operators, and has had many participants who did both. This has 
provided valuable feedback to allow correction of misguided 
standardization efforts, and has provided feedback to sort out which 
standards were actually needed. As the field has grown explosively, 
specialization has set in, and market pressures have risen, there has 
been less and less operator participation in the IETF.
===

I'm not sure if I agree that the main purpose of the IETF is to
produce standards for the Internet.  I guess this boils down to the
fact whether the processes should be vendor-driven or
consumer/customer-driven.

Naturally, from the vendor perspective, creating interoperable
standards is the most important thing. (Of course, some vendors could
use the lack of standards as a business driver as well, so this is
probably an animous opinion..)  E.g., giving advice on how to deploy
technologies (e.g., ingress filtering) is probably not seen
interesting or necessary.

From the customer/operator/consumer perspective, however, this may be
slightly different.  In a multi-vendor networks, interoperability is
of course important.  But even more, the standards which exist must be
relevant -- anything else is waste of time and energy, or even
damaging ("misleading the users to think they need X, or to achieve
the effect of X, they should do it with mechanism X").  Second, what's
more important than the standards themselves is some guidance or
advise on where/whether they are needed or useful in the first place
and if there are significant problems in deploying something, some
advice on how to go about doing that.  Of course, one could ask
whether the IETF is the right place to do that?  Well, at least some
part of that has to (and should) be done by someone else, but putting
it everything on e.g. vendors would be extremely counter-productive,
as discussed above. Third, general documents in general are also very
useful (e.g., documenting how the implementations are _not_
standards-compliant and what practical problems that causes, or what
are the issues/considerations in FOO (e.g., DNSSEC, DDNS, etc. -- or a
subset thereof)).

Therefore, I'd be quite hesitant to lower the other functions the IETF
is doing to be just supporting missions.  Producing the standards
should probably be listed in the mission, but not as the only item.

Sorry for the long note.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: John Leslie <[email-masked]>
Date: Sat, 17 Jan 2004 11:15:48 -0500

> advice (using BCP and Info documents) how to do it better?  

   This started out as a response to Pekka. And a response to Pekka is
still very important. But that will have to wait for another message,
because there's too much background which must be covered first.

>> http://www.alvestrand.no/ietf/chair/change-status.html

    In that document, Harald refers to:

http://www.alvestrand.no/ietf/chair/ietf-mission.html

which seems to state a "mission" for IETF:

" The purpose of the IETF is to create high quality, relevant, and timely
" standards for the Internet.

   This is one of those "motherhood and apple pie" statements we've been
conditioned to ignore. Much though I like Harald, I don't think it's a
good statement of our purpose, least of all mission.

   But first, let Harald explain:

" Note that this clearly positions the IETF primarily as a standards
" development organization.

   I doubt the wisdom of "positioning" the IETF "primarily" as a
"standards development organization". Clearly we do develop standards;
I'll even agree that there seems to be consensus to learn to do so better.

   But I don't believe that has ever before been our "primary" purpose.
(Surely, if it were, we'd have put more effort into doing it well.)

   And, most of all, I don't believe it wise to try to "position" the
IETF as anything other than a pretty chaotic group of people. No,
strike that -- I should have said, many pretty chaotic groups of people.

   "Positioning" the IETF makes "herding cats" look easy!

" There are other activities in the IETF; but if the IETF does not do its
" core mission, all else will quickly fade. 

   I contend that the IETF hasn't been doing a good job of "creating
high quality, relevant, and timely standards", but the Internet still
works. (So I must disagree with Harald here.)

" This is intended to be an ordered list of characteristics. Timely
" standards of low quality or that are irrelevant will not serve the
" Internet's or the IETF's needs.

   Here we get to the crux of the matter. "Timely" standards are crucial
to the operation of the Internet. Witness Microsoft. They have a wildly
successful business plan based upon "timely" standards, of whatever
quality and relevance.

   Thankfully, Microsoft has competitors. These competitors realize that
"high quality" will avail them nothing if they don't have a "timely"
alternative to the Microsoft standard. (This may be why so much gets
implemented off of "Internet drafts".)

   "Relevance" is obvious only in hindsight. Even in hindsight, it's
obvious that relevance -- in the eye of the beholder -- is a slippery
thing. The _perception_ of relevance must be built up -- usually after
a "standard" is fully described" -- in the eyes of potential users.
"Relevance" simply cannot precede "timeliness".

" This leaves open the very interesting and difficult questions of how to
" measure quality, relevance, and timeliness. The IETF has identified
" interoperability, security, and scalability as essential, but without
" attaching measurements to those characteristics.

   "Interoperability" is a long-standing tradition. "Security" is a
relatively recent buzzword -- suffering from all the problems which come
with buzzwords. "Scalability" deserves a place next to "interoperability"
as a long-standing tradition; but I'm fearful that -- as individuals --
we're attaching too many different definitions to it.

" It is important that this is "For the Internet," and does not include
" everything that happens to use IP. IP is being used in a myriad of
" real-world applications, such as controlling street lights, but the
" IETF does not standardize those applications.

   That concludes Harald's section on "The IETF Mission".

   Though it's pointless to try to substitute my wisdom for that of the
IESG, I will suggest some food for thought:

1) The IETF has always chartered Working Groups. Doesn't that belong
   fairly high in our priorities?

2) There is a long tradition of waiting for grassroots interest and
   gathering interested persons to hammer out an approach which may
   reach "rough consensus and working code". Is this no longer a good
   approach?

3) The IETF has always had a mechanism for appropriately publishing
   individual viewpoints. Is this no longer important?

4) "Timeliness" is a difficult nut to crack. Wouldn't we be better off
   creating several new paths to improve timeliness instead of placing
   blind faith in an ability to "charter in" timeliness to a standards
   process designed around a slow consensus process?

--
John Leslie <[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Sat, 17 Jan 2004 15:24:54 -0800

>timely standards for the Internet."

I think I would state it in these words:

    "The Internet Engineering Task Force provides a forum for the
    discussion and development of white papers and specifications
    for the engineering issues of the Internet."

NANOG her sisters might argue that they are also engineering fora, and I 
will agree; they deal with operational engineering, where the IETF deals 
with more of the protocol issues. I don't think that particularly 
denigrates either organization.

 From my perspective, it is less about "standards" than it is about 
"specifications" and various contributions improving our understanding. For 
the same reason, this needs to not be a discussion of whether it is the 
vendors or the users of their products; the real value of the IETF is that 
both are present and the opinions of both are treated as having value.

Lets take an example. I have been involved in QoS work, and there have been 
a number of specifications written on the subject; much of that started 
with white papers, including especially

0896 Congestion control in IP/TCP internetworks. J. Nagle.
      Jan-06-1984. (Format: TXT=26782 bytes) (Status: UNKNOWN)

0970 On packet switches with infinite storage. J. Nagle. Dec-01-1985.
      (Format: TXT=35316 bytes) (Status: UNKNOWN)

The first of these is very operational in nature, and is posed by a user of 
the technology. The second, by the same author, is far more academic in 
nature, and was seminal in the development of a variety of ideas relating 
to QoS in the succeeding decade. But it originates with a very real and 
very damaging operational problem, that of BSD 4.1's predilection to TCP 
Silly Window Syndrome and an operator's desire to minimize the impact of 
that on competing data traffic.

To leave white papers and internet drafts, many of which are never 
published as RFCs and a relatively small portion ever become standards, 
out, and to leave the discussion part out is, I think, to leave out much of 
the real value of the IETF. Yes, both of those predate the IETF as we now 
know it, but had the IETF existed then, they would have been very 
appropriate in it. Today's counterparts include papers like some I 
currently have posted (not intending to self-aggrandize, but they're the 
one's I know most quickly). The posting of questions, problems, and ideas 
is perhaps *the* key part; standards are from my perspective only one of 
the products, and perhaps a byproduct.

---

From: grenville armitage <[email-masked]>
Date: Sun, 18 Jan 2004 12:09:15 +1100

I'm not sure I see the ambiguities you assert.

Pekka Savola wrote:
	[..]
> advice (using BCP and Info documents) how to do it better?

I can't see your problem here. Clearly we know what it means to
actually deploy a network. Saying that the IETF does not deploy
networks in no way inhibits the IETF from giving guidance to good
(or purported to be good) engineering practise and trade-offs.

So Harald's observation about IETF not deploying networks is spot on.

	[..]
> products.

"Building products" isn't vague at all. By your own example the IETF
isn't building any product, although it might be a nuisance to the marketing
arm of any vendor who wished to build a product that incorporated "non approved"
protocols, techniques or technologies. No problem, vendors do that all
the time. The IETF still does not build products.

	[..]
> regulating the Internet by some means?

"Regulation" has a specific conotation here of government legislation,
rules or guidelines with operational/legal implications. Having influence
is not the same as regulating, and so Harald's characterisation here
is quite right too. There's no ambiguity. The IETF cannot prevent
things from happening even if does go to great lengths to state
considered, expert, technical opinions.

cheers,
gja
-- 
Grenville Armitage
http://caia.swin.edu.au
I come from a LAN downunder.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Jan 2004 08:59:44 +0200 (EET)

> I'm not sure I see the ambiguities you assert.

I think this is because you use the "narrow interpretation" (e.g., the
actual network deployment) of the terms -- which is fine.  My problem
with that, though, is that people can have a "broad interpretation"  
(e.g., anything regarding network deployment, including giving advice)
as well -- and the terms used are chosen such that the reader does not
know which one is correct.  This creates confusion.

> (or purported to be good) engineering practise and trade-offs.

Right, actual deployment (digging fibers, purchasing links, installing
routers, configuring the network equipment, making network plans,
etc.) doesn't seem to be in IETF's purview.  But it is not clear with
the above "broad" vs "strict" interpretation, whether "deploying
networks" includes advice on some aspects of deploying networks as
well.

A statement like "we don't deploy networks because others do it 
better" implies that the others know how to deploy networks better, 
and do deploy them better, and the IETF does not have expertise for 
that.  And if the others know how to deploy the network better, is the 
IETF the right body, with expertise, to give advice on how to do it?  

Knowing how to do something, and actually doing it, are closely tied
into each other.

With a broad interpretation, both could be excluded.  With a narrow
interpretation, maybe only actually doing it could be excluded (which
would be natural as the IETF participants are not volunteers to go
deploying networks... :-).

[[ the similar arguments apply to building products and regulating the 
Internet, so I don't repeat them again. ]]

---

From: jfcm <[email-masked]>
Date: Sun, 18 Jan 2004 07:09:20 +0100

At 00:24 18/01/04, Fred Baker wrote:
>But it originates with a very real and very damaging operational problem, 
>that of BSD 4.1's predilection to TCP Silly Window Syndrome and an 
>operator's desire to minimize the impact of that on competing data traffic.

Dear Fred,
thank you for your inputs. You point out the IETF problems I see. You say 
developers and users may meet. And the example you take is an "operator" 
(your word) predating IETF/IAB because you know it better.  This exactly 
documents the four problems I point out.

1. you describe IETF as only a forum, like "Nature" for the Science 
community. I would say it is more. It certainly is a place of dialog 
between techies and operators (I agree with your meaning of the word, John 
Klensin rebuked, of someone who operates something in using an IETF 
deliverable).

2. but it is not the polylog (the very nature of the internet) we need, 
with all the users (name them @large?) content providers, politics, 
business etc. So there is a split we often observe in here between reality 
and assumptions. You answered me that there was indeed some experimentation 
in the Standard track. I responded there is no global societal acceptance 
(including economic model, general policy etc.) nor governantal (will the 
governance accept the proposed solutions and will it be able to manage them?).

3. as such IETF it is not a place for major innovations. This calls for 
architects. The main problem of IETF is IAB and the lack of an Internet 
global model and of global development targets. You use an example from a 
time when major changes could be made, just  because they were correct. 
Today the size of the network prevents to do that easily. This is to go be 
correct direction and momentum.

4. you use examples you know. You document this way a major problem. You 
should be able to use any subject as an example. A person like you is 
trained to understand a technical state of the art summary easily in a few 
hours. But there are none of them. Read all the RFCs and the archive of 
their closed WGs.

- IETF for geeks and internuts only.
- awkward with users (demands, acceptances and usages  brainware)
- no IAB vision based upon a commonly accepted global model
- no state of the art summaries and organized RFC comments and 
experimentation reports

Experience is the mistakes of someone with memory. Why not to analyze the 
IDNA (now confirmed failure) and to try to understand how not to repeat it? 
(I opposed IDNA all the way long, but I am the first to say it was a 
complex work achieved by a hard working WG). It was useful in uncovering 
problems to be solved and some solution elements.

jfc

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 29 Jan 2004 12:46:16 -0500

I'd like to come back to this point, and try a slightly different
direction:

>     for the engineering issues of the Internet."

This seems like a reasonable characterization of the output of
the IETF.  

However, it doesn't seem to capture some of the scoping/delimiting 
that the original text did -- does the IETF discuss any and all
such issues?  Is it trying to achieve anything in particular
by documenting things?  (How) can we detect that there are issues
we should be discussing and can't?

(How) would you add to your text to provide some boundaries/
guiding lines?

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat 

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Jan 2004 19:36:39 -0500

At 12:46 PM 1/29/2004, Leslie Daigle wrote:
>I'd like to come back to this point, and try a slightly different direction:
>
>Fred Baker wrote:
>>>"The purpose of the IETF is to create high quality, relevant, and timely 
>>>standards for the Internet."
>>
>This seems like a reasonable characterization of the output of the IETF.
>
>However, it doesn't seem to capture some of the scoping/delimiting that 
>the original text did - does the IETF discuss any and all such issues?  Is 
>it trying to achieve anything in particular by documenting things?  (How) 
>can we detect that there are issues we should be discussing and can't?
>
>(How) would you add to your text to provide some boundaries/guiding lines?

Thinking out loud here, plenty of room for all to chime in. The key 
differences, if there are any, between IETF and NANOG and her sisters, and 
between IETF and IRTF, are:

Operationally, IETF discussions address advice to operators (service 
provider and enterprise, the latter being a group that our operational 
friends sometimes seem to forget) from the individuals who participated in 
the discussion, as opposed to discussions among operators. The latter are 
perfectly welcome and do happen (ptomaine, v6ops), but I would characterize 
them as often more uniquely the domain of NANOG and her sisters.

 From a research/innovation perspective, I would characterize the IETF as 
creating solutions that we in some sense know how to build, as opposed to 
playing with and learning about possible solutions that we are unsure how 
to properly build. When we built OSPF, to name one example, it was not from 
whole cloth; the algorithms were already well defined - we were simply 
figuring out how to use them. You can say quite accurately that we make our 
share of mistakes even in what we supposedly know how to do, but at least 
we can recognize when we do so. In research, 90% of ideas are truly bad 
ideas, and the other 10% are testing grounds for bits and pieces that will 
some day contribute to the solution. That is *normal*; research is 
*supposed* to be risky, to be "out of the box". When the researchers have 
done their job and the engineers come to build a solution for the Internet, 
the engineers rarely if ever simply adopt research proposals. But they are 
guided by the wisdom learned in that community, and if they lack that 
compass, they quickly are lost.

I am reminded of an academic researcher who once complained to me that "you 
write too many RFCs. You write the RFC, and we start our research on that 
RFC. We get part way into it, and you publish a new RFC." I replied to him 
that the idea is that he is supposed to do the research *before* I write 
the RFC, so that when I write the RFC I write it once and it is right. If 
he think he is doing the research afterwards, then in reality I am doing 
the research and the engineering together, in my customer's networks, and 
he is doing Quality Assurance.

We need the researchers, desperately, but not to do the engineering. We 
need them to tell us how, to be the pathfinders. We need the operational 
folks equally desperately. If nothing else, they are the canaries in the 
mine shaft, and they often can tell us what the mother lode looks like when 
we see it in the rough. And yes, we need the engineers that are paid by the 
vendors. Their marketing people are IMHO unwelcome, because they set one 
person against another for their company's gain, and a house divided 
against itself cannot stand. But if you think for a minute that the 
operators and the researchers can do this Internet thing without the 
products the vendors build, and the engineers that build them, you are 
sadly mistaken.

I am reminded of comments that I have heard in various parts of each of 
those organizations. Dave Clark, speaking to the Internet II Joint Techs 
last Tuesday, said that the IETF had forsaken innovation, and had been 
overtaken by the [evil] vendors. I submit that we - the academics, 
students, and researchers, the edge network operators that deliver 
applications running in a network, the transit network operators that 
deliver bandwidth to interconnect edges, and the vendors, whose products 
inhabit all of those networks - may not all meet together at the same time 
or with the same purpose, and we certainly all see things from different 
perspectives and in different ways. To that extent, perhaps he has a point. 
But we each play a part in the play.

Our strength and our value is not, however, that those of our particular 
stripe are somehow better than others, or more needed, or have a better 
level of understanding - that rock breaks scissors, that scissors cut 
paper, or that paper covers the rock. Our strength, rather, is that we 
bring our various perspectives together, as a builder brings together brick 
and mortar, the flexible strength of the board, the mass of the hammer, and 
the steel of the nail, and build something that will withstand the test of 
operational experience.

Let me try to say all that succinctly:

    "The Internet Engineering Task Force provides a forum for the
    discussion and development of white papers and specifications for
    the engineering issues of the Internet. This discussion builds on
    hard lessons learned in research and operational environments, and
    necessarily includes speakers from those communities. Vendors offer
    wisdom on what can be built and made to work in their products, and
    may bring customer or market issues whose owners cannot or will not
    bring themselves.

    The intended goal is well characterized as 'community memory' -
    written observations and wisdom as well as protocols and operational
    procedures defined - to enable the datagram internet to scalably
    deliver relevant services in transit and edge networks."

Is that on target? Is it too many words?

---

From: jfcm <[email-masked]>
Date: Fri, 30 Jan 2004 08:07:19 +0100

Dear Fred,
you formulated this with real majesty. Good. IETF is a wise
men pow wow where users are represented by vendors and
its favorite matter is datagram internet scalability.

This puts free softwares and new generation networks out of
its scope. They are Research from what I understand. Why not?

Would then the question not be to define the IAB Mission?
Should not someone take care of modelization and innovation?
jfc

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Jan 2004 12:14:13 -0800

At 11:07 PM 1/29/2004, jfcm wrote:
>This puts free softwares and new generation networks out of its scope. 
>They are Research from what I understand. Why not?

I don't think the IETF tells people how to charge; the software can be free 
or not. I don't think the IETF cares, and I don't know that being free 
makes it research.

As to next generation networks, I have a little rant on the topic. There 
are two terms that go around that drive me nuts:
    "Next Generation Network"
       Marketing term: it means "the network or networking technology I
       would like to sell you"
    "Legacy technology"
       Marketing term: it means "the technology you already have that I
       would like to replace with my Next Generation Network"

An example of this usage showed up recently on the manet list: I was 
proposing adding manet capabilities to OSPF, so that manet networks could 
easily be part of a larger network that contained more traditional regions 
as well. The respondent asked whether I had considered building a 
manet-only protocol, since the wired networks were legacy networks destined 
for the dustbin and wireless is the only thing that will be present in the 
future. My word... If you believe that, I have a bridge to sell you...

Market-babble doesn't belong in the IETF. But the solid engineering that 
the market-droids babble about most certainly does.