Re: The IETF Mission

[JFC (Jefsey) Morfin]

At 16:52 06/02/04, [EMAIL PROTECTED] wrote:
To create open technical standards and identify best practices that are 
useful to and
adopted by the world internet communtity and the public at large
Along your lines, what about:
"To propose open technical standard and identify best practices striving to 
address the multifolded needs of the public at large, through its use of 
the internet part of the digital ecosystem".

- "useful" only is not a very exciting challenge.
- one cannot develop something which will be adopted. One can only observe 
it has been adopted.
- RFCs respect is impotrant, but should not come first every and all user 
alternative needs?
- Internet is to converge with other infromation mediums, since the world 
expects one single service ubiquitous continuity.

jfc

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: The IETF Mission

[Iljitsch van Beijnum]

On 10-feb-04, at 1:37, Dean Anderson wrote:

To work with suppliers, consortia, and other standards bodies 
to
develop consensus and facilitate interoperability.
So how does "the IETF" do this? Talking to others only works in a 
top-down organization, but not in a bottom-up organization. I don't see 
how a situation where the IETF, through its internal processes, reaches 
rough consensus, and then would have to negotiate with external 
entities, could work.

I think it's important that the IETF can operate autonomously, without 
"working" with anyone. If suppliers, consortia and other standards 
bodies have input to the IETF, they can participate like anyone else.

Re: The IETF Mission

[Dean Anderson]

Ok, here is a revised version with the current feedback.

This is the section from the ANSI Mission statement:

  Due Process. All objections shall have an attempt made towards their 
  resolution. Interests who believe they have been treated unfairly shall 
  have a right to appeal.

It seems that some mention should be made about due process at the IETF.






The IETF, an activity of the Internet Society, is a technical protocol
standards organization.  Its principal goals are:

    To create open technical standards and identify best practices
that are useful to and adopted by the world internet communtity and the
public at large.

To identify current and emerging protocol requirements, and share 
best practices.

To facliitate the participation of all affected and interested
parties and develop consensus.

To solicit the input of a diverse group of interests and 
participants in the formation of protocol standards.

To provide a fair and open process in the specification and
movement of future standards throughout the standardization process, with
early and equal access to specifications.

To use a fair and open process in the resolution of disputes so
that any person or organization with a claim of unfair treatment has an
avenue for appeal.

To work with suppliers, consortia, and other standards bodies to 
develop consensus and facilitate interoperability.
   

Re: The IETF Mission

[EdLevinson]

At 03:49 PM 2/4/04 -0500, Dean Anderson wrote:
I propose the following as a
mission statement for the IETF:
IETF is a technical protocol standards organization.  Its principal
goals 
are:
    To create open, technical
standards that will be useful to and 
adopted by the world internet communtity and the public at
large.
Well put, a concise statement of mission.  I suggest that the rest
(almost) addresses how to do that; a principles of operation statement
which could be a separate statement.  To clearly separate the two I
suggest adding "current practices" to the above.  For
example:
    To create open technical
standards and identify best practices that are useful to and 
adopted by the world internet communtity and the public at
large.
Other changes, dropped comma after open and changed "will be"
to "are".  [I think that strengthens the
statement.]
Ed
   
To identify current and emerging protocol requirements, and share 
best practices.
    To facliitate the
participation of all affected and interested
parties and develop consensus.
    To solicit the input of a
diverse group of interests and 
participants in the formation of protocol standards.
    To provide a fair and open
process whereby any party that believes 
it has been treated unfairly has the right to appeal.
    To work with suppliers,
consortia, and other standards bodies to 
develop consensus and facilitate interoperability.

Ed Levinson  47 Clive Street 
Metuchen, NJ 08840  USA
Coach & Technology Consultant
T: +1 732 494 1606  F: +1 732 494 4495
mailto:[EMAIL PROTECTED]
http://www.ResultsLifeCoaching.com

Re: The IETF Mission

[grenville armitage]

much as i hate "me too" messages, i think joel makes a good point.

cheers,
gja

"Joel M. Halpern" wrote:
> 
> I do not think "appeals" belongs in our mission and vision statement.  They
> are a mechanism to achieve openness and accountability, not the purpose of
> the organzation.
> 
> Yours,
> Joel M. Halpern

[..]
-- 
Grenville Armitage
http://caia.swin.edu.au
I come from a LAN downunder.

Re: The IETF Mission

[Joel M. Halpern]

I do not think "appeals" belongs in our mission and vision statement.  They 
are a mechanism to achieve openness and accountability, not the purpose of 
the organzation.

Yours,
Joel M. Halpern
At 01:47 PM 2/5/2004 -0500, Dean Anderson wrote:
How about this:

 To provide a fair and open process whereby any party that
 believes it has been treated unfairly has the opportunity to appeal.
On Wed, 4 Feb 2004, james woodyatt wrote:

> On 04 Feb 2004, at 12:49, Dean Anderson wrote:
> >
> > To provide a fair and open process whereby any party that
> > believes
> > it has been treated unfairly has the right to appeal.
>
> I'd prefer this:
>
>   To use a fair and open process, even in the resolution of disputes,
>   in which any person with a claim of unfair treatment has an avenue
>   for appeal.
>
> I don't much like the idea of artificial legal entities, i.e. political
> parties, having "rights".  It's a minor nit, I know— call me a radical
> hippie, if you must.
>
>
>

Re: The IETF Mission

[Bill Manning]

% How about this:
% 
%  To provide a fair and open process whereby any party that
%  believes it has been treated unfairly has the opportunity to appeal.


...over and over and over and over and over and over and over

Methinks this needs a bounds check.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

Re: The IETF Mission

[Dean Anderson]

How about this:

 To provide a fair and open process whereby any party that
 believes it has been treated unfairly has the opportunity to appeal.


On Wed, 4 Feb 2004, james woodyatt wrote:

> On 04 Feb 2004, at 12:49, Dean Anderson wrote:
> >
> > To provide a fair and open process whereby any party that 
> > believes
> > it has been treated unfairly has the right to appeal.
> 
> I'd prefer this:
> 
>   To use a fair and open process, even in the resolution of disputes,
>   in which any person with a claim of unfair treatment has an avenue
>   for appeal.
> 
> I don't much like the idea of artificial legal entities, i.e. political 
> parties, having "rights".  It's a minor nit, I know— call me a radical 
> hippie, if you must.
> 
> 
> 

Re: The IETF Mission

[james woodyatt]

On 04 Feb 2004, at 20:59, james woodyatt wrote:
On 04 Feb 2004, at 12:49, Dean Anderson wrote:
To provide a fair and open process whereby any party that 
believes
it has been treated unfairly has the right to appeal.
I'd prefer this:

To use a fair and open process, even in the resolution of disputes,
in which any person with a claim of unfair treatment has an avenue
for appeal.
Drat.  Scratch out the characters ", even" in the above.  That was bad 
logic on my part.  Apologies all around.  I'll shut up now.

--
j h woodyatt <[EMAIL PROTECTED]>

Re: The IETF Mission

[james woodyatt]

On 04 Feb 2004, at 12:49, Dean Anderson wrote:
To provide a fair and open process whereby any party that 
believes
it has been treated unfairly has the right to appeal.
I'd prefer this:

To use a fair and open process, even in the resolution of disputes,
in which any person with a claim of unfair treatment has an avenue
for appeal.
I don't much like the idea of artificial legal entities, i.e. political 
parties, having "rights".  It's a minor nit, I know— call me a radical 
hippie, if you must.

--
j h woodyatt <[EMAIL PROTECTED]>

Re: The IETF Mission

[Harald Tveit Alvestrand]

Thanks Dean - this collection was actually quite informative!

Harald

--On 4. februar 2004 15:49 -0500 Dean Anderson <[EMAIL PROTECTED]> wrote:

Openness. Any materially affected and interested party has the ability to
participate.
Balance. The standards development process should have a balance of
interests and participants from diverse interest categories shall be
sought.
Due Process. All objections shall have an attempt made towards their
resolution. Interests who believe they have been treated unfairly shall
have a right to appeal.





pgp0.pgp
Description: PGP signature

Re: The IETF Mission

[Dean Anderson]

> Fred Baker wrote:
> > 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.

This misses a great deal.  I think one needs to consider the Mission of
other standards organizations such as IEEE, ANSI, the ITU, and The Open
Group, to name a few examples:

The mission of The Open Group is to drive the creation of Boundaryless 
Information Flow achieved by:

* Working with customers to capture, understand and address current 
and emerging requirements, establish policies, and share best practices;
* Working with suppliers, consortia and standards bodies to develop 
consensus and facilitate interoperability, to evolve and integrate 
specifications and open source technologies;
* Offering a comprehensive set of services to enhance the operational 
efficiency of consortia; and
* Developing and operating the industry's premier certification 
service and encouraging procurement of certified products.


IEEE Vision and Mission

VISION

To advance global prosperity by fostering technological innovation, 
enabling members' careers and promoting community world-wide.


MISSION

The IEEE promotes the engineering process of creating, developing, 
integrating, sharing, and applying knowledge about electro and information 
technologies and sciences for the benefit of humanity and the profession.


ANSI MISSION

To enhance both the global competitiveness of U.S. business and the U.S. 
quality of life by promoting and facilitating voluntary consensus 
standards and conformity assessment systems, and safeguarding their 
integrity

Cardinal Principals

Openness. Any materially affected and interested party has the ability to 
participate.

Balance. The standards development process should have a balance of 
interests and participants from diverse interest categories shall be 
sought.

Due Process. All objections shall have an attempt made towards their 
resolution. Interests who believe they have been treated unfairly shall 
have a right to appeal.

Consensus. More than a majority, but not necessarily unanimity.

> >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."

I don't think it has anything to do with "community memory", nor is it 
limited to the 'datagram internet', nor is it even limited to services in 
'transit and edge netorks'. Quite obviously, it is useful to peering and 
private and other kinds of networks, but the types of networks aren't 
important. What is important is that the stardards are techincally useful, 
and publicly deliberated.

Re: The IETF Mission

[Dean Anderson]

I propose the following as a mission statement for the IETF:

IETF is a technical protocol standards organization.  Its principal goals 
are:

To create open, technical standards that will be useful to and 
adopted by the world internet communtity and the public at large.

To identify current and emerging protocol requirements, and share 
best practices.

To facliitate the participation of all affected and interested
parties and develop consensus.

To solicit the input of a diverse group of interests and 
participants in the formation of protocol standards.

To provide a fair and open process whereby any party that believes 
it has been treated unfairly has the right to appeal.

To work with suppliers, consortia, and other standards bodies to 
develop consensus and facilitate interoperability.
   

Re: The IETF Mission

[Leslie Daigle]

I think it's on track, as a description of the "common interest"
(a phrase someone used earlier).
I'm still itching for something that acts as a delimeter -- how
do we know whether we, collectively, should be working on X or
ignoring Y?  How can we know when we are "succeeding" at our
mission?
Harald outlined some possibilities in terms of the
scope of the work, and people didn't seem to resonate with that
approach.
Is our mission to collectively work on some selection of things
of common interest?  Do we have common view on means of determining
relevance in "relevant services in transit and edge networks"?
Are we obligated, by this statement of interest, to work on anything
someone (or a large enough collection of "someones") considers
relevant at a given point in time?
Someone earlier raised the point that the description of the space
in which we work (the IETF's scope) may not be the description of
the work that we collectively take on -- I guess I'm wondering whether
we can characterize the subset in some constructive way, so that
it will be clearer to us, and to communities trying to work with
us, what we should/will put energy into at a given point in time.
Leslie.

Fred Baker wrote:
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?

Re: Behaviour on IETF lists (Re: The IETF Mission)

[Dean Anderson]

Harald,

It seems that you haven't quite followed the thread, or read the messages.

This issue was brought up in a comparison between Nanog and the IETF by
Fred Baker, who apparently found little difference between the IETF and
Nanog.  It is quite valid to make comparisions to the missions of other
organizations, so he brings up a valid point, which deserves equally valid
disagreement.

The events involving Susan Harris occurred, and I am reporting them to
distinguish the IETF from Nanog in response to a post comparing the IETF
to NANOG. Many people no doubt think her conduct was improper.  Reporting
improper conduct is not a personal attack.  The act I am criticizing was
made in her official role at Nanog, and reflects on Nanog as an
organization. This was not a private or personal act.  It has nothing to
do with her personally except that she is a person responsible for Nanog,
and has authority at Nanog, and she made the decsisions which are being
criticized.  Her official decisions reflect on Nanog just as your official
decisions reflect on the IETF.  If you make bad decisions, they will
reflect badly on the IETF, and you and the IETF will deserve criticism.  
Such criticism is not a personal attack. You are misusing the term.

Susan Harris may be an nice person. I've never met her in person. I don't
know anything personal about her to attack.  But sometimes nice people
behave in ways that are quite obviously improper. Documenting, reporting,
criticizing, and complaining about such behavior is not a personal attack.
For your information and reference, a 'personal attack' is where one
attacks a personal trait of the person, rather than their position.  I've
attacked her position as represented by her official decisions regarding
Nanog, not her personally.

Sometimes people try to deflect criticism by trying to call it a personal
attack. This in not the first time that people have misused the term
'personal attack' when their friends were being criticized.  Perhaps you
are letting your friendship get in the way?

Quite obviously, I can't take it to Nanog--apparently you didn't read my
message.  Certainly you wouldn't make such a frivolous statement if you
had read it.  But your suggestion clarifies and obvious difference between
Nanog and the IETF: there is no one in authority other than Susan
Harris--there is no one to appeal her decisions to.  IETF decisions, as
you know, can be appealed.

But she also did some things that are relevant to the IETF.  Besides
halting my participation in Nanog, she also halted my participation in the
RADB. At the time, Av8 was participating in the RADB and had RADB objects.  
It seems to me that denying my participation in the RADB may be a
violation of IETF/ISOC/ICANN rules.  And this should be redressed.


Thanks,

Dean Anderson
CEO
Av8 Internet, Inc


On Fri, 30 Jan 2004, Harald Tveit Alvestrand wrote:

> Dean,
> 
> the subject of the IETF mission is not particularly relevant to bashing 
> NANOG policies, or personal attacks on persons for their activities within 
> NANOG.
> Nor are personal attacks appropriate on the IETF list.
> If you want to quarrel about NANOG topics, at least change the subject.
> Or better yet, take it to NANOG.
> 
> --On 30. januar 2004 11:46 -0500 Dean Anderson <[EMAIL PROTECTED]> wrote:
> 
> > So Nanog is quite a bit different from the IETF, and, in my opinion,
> > should not be associated with or compared to the IETF.  Actually being
> > right on concrete issues is something that carries no weight with Nanog,
> > but it does carry weight with the IETF.
> 
> 
> 
> 

Re: The IETF Mission

[Fred Baker]

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. 

pgp0.pgp
Description: PGP signature

Behaviour on IETF lists (Re: The IETF Mission)

[Harald Tveit Alvestrand]

Dean,

the subject of the IETF mission is not particularly relevant to bashing 
NANOG policies, or personal attacks on persons for their activities within 
NANOG.
Nor are personal attacks appropriate on the IETF list.
If you want to quarrel about NANOG topics, at least change the subject.
Or better yet, take it to NANOG.

--On 30. januar 2004 11:46 -0500 Dean Anderson <[EMAIL PROTECTED]> wrote:

So Nanog is quite a bit different from the IETF, and, in my opinion,
should not be associated with or compared to the IETF.  Actually being
right on concrete issues is something that carries no weight with Nanog,
but it does carry weight with the IETF.





pgp0.pgp
Description: PGP signature

Re: The IETF Mission

[Dean Anderson]

> 
> 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:

Nanog should not be compared to the IETF.  Nanog is a forum that has
promoted ignorance of the law or perhaps even tolerance of illegal
activity, and specifically promotes misinformation of network operators
with respect to the Electronic Communications and Privacy Act (ECPA) and
Computer Fraud and Abuse Act (CFAA). Nanog does this by selective
suppression of discussion on the subject and the suppression of
participation of anyone who would refute the notion that the ECPA only
applies to "common carriers".  Merit and Nanog describe themselves as
"educational".  The failure to educate Network Operators on the legal
aspects of their profession is, in my opinion, nothing less than
reprehensible.  Quite obviously, there are legal aspects to internet
service operation just as there are legal aspects to business. No
reputable business school would fail to provide adequate courses in
business law, or fail to discuss the legal aspects of business with
students. Nanog claims to be an educational organization, yet it fails to
live up to any reasonable standard of education, and goes further with its
selective suppression.  The selective suppression reveals an agenda of
misinformation that goes beyond simply not educating.

Over the years, I have done extensive research on the ECPA, and the CFAA.
I have employed lawyers on the subject, and have supporting documents such
as legal, uptodate copies of the statutes, the House and Senate reports on
the ECPA and the CFAA, and the Model Criminal Code, as well as an
extensive library of case law. While the House and Senate reports on the
ECPA speak extensivly about Email and Remote Computing Services, many
people on Nanog have posted that the ECPA does not apply to ISPs. Yet
despite having all this information, Susan Harris has asked me not to
refute those people who claim that the ECPA does not apply to ISPs or
Email.

In January of 2000, Susan Harris asked me (only me) to stop posting on the
subject, in reference to a specific incident.  She didn't want me to
refute people on the topic. She did not make any requests of anyone else
to stop, and the "bashing" continued for two or three days, until news
reported that law enforcement acted in a way that vindicated what I was
saying. After I posted this vindication, which came after several days of
bashing in which I did not participate, she removed my posting privileges.  
Actually being right on concrete issues is not something that is respected
on Nanog. My posts were also informative, respectful, and well supported
with citations.  Supposing this were off-topic, it would be appropriate to
ask everyone to stop. But of course, it isn't any more off-topic for
Network operators to learn about the ECPA than it is for business school
candidates to learn about business law.

While Nanog did have a DOJ person speak in October, 2000, that
presentation has been wildly misquoted, and it barely addressed the civil
aspect of the ECPA.  The CFAA was not discussed.  False information is
still posted on Nanog on the topic, which has been brought up by others.
And the topic is clearly of interest to network operators, because it
keeps coming up.  

For example, I was not allowed to correct claims made in June 2002 by
Steve Bellovin that "what you say is correct for *telephone* companies,
but not ISPs.".  Bellovin attributes this statement to the DOJ
presentation. But the DOJ presentation does not in fact say that. Though I
concede that it is easy to take the slides out of context, this goes well
beyond that.  Bellovin makes other mistakes to give the impression that
only common carriers need be concerned with the ECPA.  Bellovin also uses
claims of "discussions with prosecutors" to substantiate his claims. But
his claims are refuted by the statute text, the Congressional Reports, and
the case law.  Unfortunately, few are familar with that material allowed
to post.  Some of the material is obscure and costs money to obtain. So I
am limited to privately emailing information to the people who posted the
original questions.  Others, perhaps interested in the topic, but who
didn't post, are misled.

So Nanog is quite a bit different from the IETF, and, in my opinion,
should not be associated with or compared to the IETF.  Actually being 
right on concrete issues is something that carries no weight with Nanog, 
but it does carry weight with the IETF.

Dean Anderson
CEO
Av8 Internet, Inc

Re: The IETF Mission

[jfcm]

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
At 01:36 30/01/04, Fred Baker wrote:
   "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."

Re: The IETF Mission

[Fred Baker]

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."
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."
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 build

Re: The IETF Mission [Re: Summary status of change efforts - Updated Web page]

[Leslie Daigle]

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."


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."
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 PROTECTED]
---

Re: The IETF Mission

[Spencer Dawkins]

- Original Message - 
From: "Bob Braden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 19, 2004 1:01 PM
Subject: Re: The IETF Mission

>   *> Is the standard for Informational currently that onerous?
>
> Certainly not.  But the community (and especially its chosen
> leadership) need to believe in the importance of using Informational
> to capture important documents and ideas as RFCs.
>
> Bob Braden

Just to be clear - in
http://www1.ietf.org/mail-archive/ietf/Current/msg23935.html I made a
snotty remark wondering what the average time-to-publish from first
draft to RFC for Informational RFCs is.

I was trying to say what Bob said more clearly (first time that's
happened today, of course). If you look up "Informational RFC" in
2026, it's not that bad. If we lived in the world of 2026, we would
publish more of them, especially individual drafts. HIP Architecture
is a wonderful example of an Informational RFC-to-be.

Spencer

Re: The IETF Mission

[grenville armitage]

Vernon Schryver wrote:
> 
> > From: grenville armitage <[EMAIL PROTECTED]>
> 
> > ...
> > then that's a problem we can fix without creating an indestructable I-Ds.
> > ...
[..]
> I have never failed to find copies somewhere
> on the net.  Today the only aspect of an I-D that expires after 6 months
> is the endorsement implicit in a copy at venera.isi.edu or www.ietf.org.

That's the extent of my observation. The implicit endorsement of
storing an I-D at www.ietf.org should be temporary. If people want to
store/publish/whatever a document elsewhere, well, that's fine and dandy.
This thread was (I thought) about an IETF-endorsed archivive of I-Ds,
which I object to as unnecessary. I suspect we may agree.

cheers,
gja

Re: The IETF Mission

[Vernon Schryver]

> From: grenville armitage <[EMAIL PROTECTED]>

> ...
> then that's a problem we can fix without creating an indestructable I-Ds.
> ...

IETF rules to the contrary, I-Ds are indestructable for anyone who
cares to look for them.  Every several months I'm moved to point to
classic I-Ds that should have been destroyed as proof that almost
anyone can submit an I-D that says almost anything, no matter
how...ah...controversial.  I have never failed to find copies somewhere
on the net.  Today the only aspect of an I-D that expires after 6 months 
is the endorsement implicit in a copy at venera.isi.edu or www.ietf.org.

Today an endorsement of some sort is the only difference between having
your ideas heard by self-publishing and having them officially published.
The web is taking us a major step forward to 400 or 500 years ago when
good ideas were self-published and readers didn't need the moderation
of a Rupert Murdoch or the IETF.  I don't know what the academic
publish-or-perish, RIAA, and other commercial and mass media worlds
will do to replace their citation indecies, royalties, and advertising
revenues, and I don't much care.

I'm not saying anything against WGs producing Informational RFCs. 
I'm only pointing out that calls to have the IETF Mission Statement
"broaden the scope and quantity of documents to be published" suggest
ignorance of search engines or needs to have things endorsed by the IETF.


] From: Fred Baker <[EMAIL PROTECTED]>

] I don't know that we're changing anything in what the IETF does. What is 
] happening is that the IETF is growing up and taking control of its own 
] destiny in a variety of ways, and trying to clean up its own processes. In 
] all the *other* problems it tries to solve, the IETF tries to say what 
] problem it is solving sometime before finishing solving it, if for no other 
] reason so that it can decide whether it did in fact solve it. Same here.

The facilitators hired by H-R departments to run mission statement
"off-sites" always say all of that.  They are always perfectly sincere
and well meaning.  Those good intentions do not change the fact that
trying to write a mission statement changes the organization.  If an
organization lacks an unstated consensus purpose, then writing a mission
statement is unlikely to create one.  On the other hand, trying to
write one exposes any lack of consensus and turns into a race to the
Dilbert Standard of advocating all virtues, condemning all vices, and
creating new mandates such as "ad hoc WGs" and "archived I-Ds."

You could be right and I might be wrong if much this thread were not
filled with talk about turning the IETF an unfunded Reed Elsevier.

] ...
] Once we have decided that we did in fact solve the problem before us, I 
] don't know that the bumper sticker gets us all that much further. But the 
] bumper sticker can be helpful when we are asking the questions "what are we 
] trying to accomplish?" and "are we accomplishing it?".

It's one thing to consider those questions and something else to write
a "mission statement."  Mission statement facilitators always say the
only purpose is to consider those to questions, but the results are
what they always are.  Those results are related to the fact that they're
officiously titled "Mission Statements" instead of "ad hoc comments
about what we're trying to do and how well we're doing it."

I know many of you must have been through Mission Statement charades.
Have you ever seen one that with 12 months hindsight was not a waste
of time or worse?  My personal experience suggests that "write a mission
statement" means the same as "jump the shark."  See
http://www.google.com/search?q=%22jump+the+shark%22


Vernon Schryver[EMAIL PROTECTED]

Re: The IETF Mission

[grenville armitage]

Bob Braden wrote:
> 
>   *>
>   *> If it is important, it'll progress the work of some group in the
>   *> IETF and be archived as an RFC. If it (the I-D) doesn't capture work
>   *> well enough to be archived as an RFC then it ought to fade from IETF
>   *> I-D storage.
> 
> Grenville,
> 
> Not all important ideas enter the working group process and emerge
> as standards,

True, but to be fair, I actually said "...to be archived as an RFC." Although
I might appear to have succumbed to "RFC == standard" mentality, I haven't
really :)

> and the fact that some working group chooses not to
> "capture" an document does not make it necessarily unworthy of
> preservation.

Yes, that's true. I simply believe that we already have a mechanism in
our posession for WGs (who are the best judges) to archive their developed
wisdom and insights - the Informational RFC. If WGs aren't using this method
then that's a problem we can fix without creating an indestructable I-Ds.
I'd hope. (I've used Informational status for this very purpose myself a
few times, so I'm biased.)

>  After all, the technical problems evolve, and our
> solutions need to evolve too; ideas that did not make it at one
> stage may turn out to be important in the future.  And, I believe
> you are surrendering too easily the over-emphasis on standards
> that Fred decried in his message.

Hopefully you were thinking of someone else ;)

> 
>   *>
>   *> Is the standard for Informational currently that onerous?
> 
> Certainly not.  But the community (and especially its chosen
> leadership) need to believe in the importance of using Informational
> to capture important documents and ideas as RFCs.

Absolutely agree.

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

Re: The IETF Mission

[Eric A. Hall]

On 1/19/2004 3:47 PM, Vernon Schryver wrote:

>>> Not all important ideas enter the working group process and emerge 
>>> as standards, and the fact that some working group chooses not to 
>>> "capture" an document does not make it necessarily unworthy of 
>>> preservation.  ...
> 
>> Another approach here is to allow for the creation of ad-hoc WGs.
>> That would provide a cleaner path for tangential documents that don't
>> fit ...
> 
> Let's see if I've got all of this straight:

No (although I'm not really sure you tried). "Ad-hoc" isn't supposed to
mean 'anything goes', but about providing an alternative channel to BOFs.

I'm sure there was a time where discouraging potentially frivolous efforts
by imposing a high cost of entry was considered a positive benefit of the
design. It still might be. If the objective is to broaden the scope and
quantity of documents to be published, however, lowering that bar would be
useful. Speaking for myself and others, getting volunteer part-timers from
multiple different continents to the same meeting is a pain, and the
payoff is so far into the future and marginal that it usually isn't worth
the cost involved.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: The IETF Mission

[Fred Baker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Good grief.

I don't know that we're changing anything in what the IETF does. What is 
happening is that the IETF is growing up and taking control of its own 
destiny in a variety of ways, and trying to clean up its own processes. In 
all the *other* problems it tries to solve, the IETF tries to say what 
problem it is solving sometime before finishing solving it, if for no other 
reason so that it can decide whether it did in fact solve it. Same here.

I can't speak for the others who took a crack at a mission statement, but 
I'll bet that each would articulate what he was trying to do about the same 
way that I do: I was trying to state in a few pithy words what I thought 
was important about the IETF. The purpose of the mission statement is to 
say what is core - what it is that is so important that if we screw it up 
we screwed up. If we tried to describe "what Vernon does all day" and wound 
up saying something about wearing a dress, my guess is that we could be 
accused of screwing up. If we described "what Vernon does all day" in terms 
of having ideas and articulating them, perhaps we hit closer. If we were 
trying to figure out processes to ensure that Vernon succeeded in doing 
what was important, processes that helped the latter might be more 
valuable. Am I close? The same is true of the IETF; hence the question.

I proposed the wording that I did because to me, the most important things 
the IETF does include
  - discussion of engineering issues in the Internet,
  - improvement of understanding of engineering issues in the Internet,
  - creating white papers that embody that understanding of engineering
issues in the Internet, and
  - creating specifications for protocols that improve the engineered
behavior of the Internet.

Some of the outcomes of the fourth bullet get labeled "standards", because 
we agree to call them that and because we agree to implement them, but by 
no means do all, and certainly the items on the third bullet don't. The 
observation that of all documents that have RFC numbers about 2/7 (1014 out 
of 3681) are Proposed Standards, Draft Standards, Full Standards, or Best 
Current Practice documents is not a call for more documents. It is also not 
a call to archive documents that are not felt to contribute valuable 
insights to our community memory. It is an observation of fact. 2/3 of the 
documents in the RFC series are *not* specifications. They are discussion 
of problems, of architecture, of requirements, and so on. They are the 
documents that a purely standards-oriented organization would never pursue, 
but which improve our understanding of the subject at hand.

Once we have decided that we did in fact solve the problem before us, I 
don't know that the bumper sticker gets us all that much further. But the 
bumper sticker can be helpful when we are asking the questions "what are we 
trying to accomplish?" and "are we accomplishing it?".

Dilbert may have something to say about it, but I personally am not a 
management consultant...
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 7.0.3 for non-commercial use 

iQA/AwUBQAxi7m4xHWxyLJtDEQK5kQCgkV7NOuJq0UOMu1k4AelJZe0x9bEAn3vD
dsQj42jIjZ4KbZgLRQKQyUGX
=ZcIY
-END PGP SIGNATURE-

Re: The IETF Mission

[Vernon Schryver]

> > Not all important ideas enter the working group process and emerge
> > as standards, and the fact that some working group chooses not to
> > "capture" an document does not make it necessarily unworthy of
> > preservation.  ...

> Another approach here is to allow for the creation of ad-hoc WGs. That
> would provide a cleaner path for tangential documents that don't fit
> ... 

Let's see if I've got all of this straight:

 - The IETF is working on a Dilbert Standard compliant Mission Statement.
  The Dilbert Mission Statement Standard requires foursquare support
  of all virtues and opposition to all vices, without unnecessary
  (read "any") limitations.

 - There are many wonderful ideas that are so awesome that if they were
  self-published, their publishers cannot be slashdotted and would
  never be indexed by Google.  To remedy this unfair lack of publishers
  and de facto censorship, the IETF will go into competition with the
  ACM, IEEE, etc. in both the refereed academic publish-or-perish
  business (e.g. CACM or *Transactions) and the random research notes
  business (SIGCOMM).

 - Salescritters, marketoons, and trade rag espurts find it inconvenient
  to utilize the IETF imprimatur by submitting I-Ds (possibly pushed
  to Informational) and then advertising compliance.  To fix this
  terrible shortcoming of the IETF Standards Process that hinders
  innovatation by Microsoft and other leading edge organizations, the
  new IETF Mission Statement will require that anyone who wants a WG
  can have one.

I think those are excellent proposals, although perhaps not for the
same reasons as other adovcates.  I've been complaining about nonsense
I-Ds and write-only RFCs for many years.  The most effective way to
relive the pressure for junk RFCs and nonsense IDs is to make IETF's
stamp of approval meaningless by giving it to anything and everything
that comes along.  Within a matter of at most a year or two, RFCs might
go back to what they were 20 years ago.

To solve any funding problems or overwork of the IESG,
http://www.ietf.org/html.charters/wg-dir.html will become an automated
index of links much like http://reshmeat.net/ and we'll do away with
Last Calls. 

Let's hurry up and advance or at least archive these IDs before they expire:

  draft-terrell-internet-protocol-t1-t2-ad-sp-06.pdf
  draft-terrell-iptx-dhcp-req-iptx-ip-add-spec-00.pdf
  draft-terrell-iptx-dns-req-iptx-ip-add-spec-03.pdf
  draft-terrell-iptx-spec-def-cidr-ach-net-descrip-01.pdf


Vernon  Schryver[EMAIL PROTECTED]

Re: The IETF Mission

[Pekka Savola]

On Mon, 19 Jan 2004, Eric A. Hall wrote:
> Another approach here is to allow for the creation of ad-hoc WGs. That
> would provide a cleaner path for tangential documents that don't fit
> within existing charters, and would facilitate broader group review of
> independent submissions. Speaking for myself, I've written some drafts
> that I would have liked to seen progressl, but didn't fit in existing WGs,
> and the requirements for new WGs were too stringent to pursue. This latter
>  issue is also one of the reasons behind the relatively low involvement
> from the developing-world community, and exacerbates the feelings of
> powerlessness and resentment that end up costing us recovery time fighting
> off the well-meaning fools who would make this problem worse by handing
> control to organizations with even higher barriers of entry.

Maybe you have a common(?) fallacy that once a WG is established, you 
start to magically a better and broader review of the drafts.

Often this is not the case.

But the core point is, I think, how can one attract the reviewers or 
people in general to read and send feedback on an idea which has been 
documented in an Internet-draft.  This is obviously a difficult 
problem, as everybody probably thinks their work is special.

One thing which *might* make it easier, for the drafts which relate to
existing technologies, is if there were "maintenance teams" for the
core protocols, with mailing-lists one could spam one's ideas to,
hoping for feedback from the people interested in a subject.  Not sure
if that would help significantly though..
 
-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: The IETF Mission

[Eric A. Hall]

On 1/19/2004 1:01 PM, Bob Braden wrote:

> Not all important ideas enter the working group process and emerge
> as standards, and the fact that some working group chooses not to
> "capture" an document does not make it necessarily unworthy of
> preservation.  After all, the technical problems evolve, and our
> solutions need to evolve too; ideas that did not make it at one
> stage may turn out to be important in the future.

Another approach here is to allow for the creation of ad-hoc WGs. That
would provide a cleaner path for tangential documents that don't fit
within existing charters, and would facilitate broader group review of
independent submissions. Speaking for myself, I've written some drafts
that I would have liked to seen progressl, but didn't fit in existing WGs,
and the requirements for new WGs were too stringent to pursue. This latter
 issue is also one of the reasons behind the relatively low involvement
from the developing-world community, and exacerbates the feelings of
powerlessness and resentment that end up costing us recovery time fighting
off the well-meaning fools who would make this problem worse by handing
control to organizations with even higher barriers of entry.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: The IETF Mission

[Bob Braden]

  *> 
  *> If it is important, it'll progress the work of some group in the
  *> IETF and be archived as an RFC. If it (the I-D) doesn't capture work
  *> well enough to be archived as an RFC then it ought to fade from IETF
  *> I-D storage.

Grenville,

Not all important ideas enter the working group process and emerge
as standards, and the fact that some working group chooses not to
"capture" an document does not make it necessarily unworthy of
preservation.  After all, the technical problems evolve, and our
solutions need to evolve too; ideas that did not make it at one
stage may turn out to be important in the future.  And, I believe
you are surrendering too easily the over-emphasis on standards
that Fred decried in his message.

  *> 
  *> Is the standard for Informational currently that onerous?

Certainly not.  But the community (and especially its chosen
leadership) need to believe in the importance of using Informational
to capture important documents and ideas as RFCs.

Bob Braden

Re: The IETF Mission

[Bob Braden]

  *> This means drastically lowering the standards for what can be published 
  *> as an RFC. (Note that this brings us closer to what RFCs used to be 15 
  *> years or so ago.) Another way to do it would be to simply archive all 

I do not believe that it means lowering the standards at all, in
general.  In general, the documents we should be publishing as RFCs,
but are allowing to disappear into long-dead Internet Drafts, are every
bit as good quality as the RFCs we are publishing today (if not
better!).

Example: The RFC Editor has been pushing to get the current plateau of
the technical specification of HIP published as an RFC.  It's like
pulling teeth, for some reason, but hopefully we will make it.  The
current HIP architecture document is an important contribution that will
be a valuable reference to future Internet techies, regardless of the
future trajectory of the HIP protocol.

BTW, when you said 15 years you really meant 25, back to the late
ARPAnet and early Internet days.  15 years ago is relatively recent,
really part of "modern times" for the Internet community.  For example,
the Host Requirements RFCs (1122, 1123) were published 15 years ago.  I
don't think you would be lowering current standards to reach that
level.

  *> drafts. I agree this has the unpleasant side effect that all those 
  *> drafts that become obsolete (or are so from inception) stay around 
  *> forever. But it's still better than the current situation, where making 
  *> something an RFC means an incredible amount of work for many people, 

It is true that writing quality documents, no matter what
you call them, is always an "incredible amount of work."  Work well
spent, I believe.

Bob Braden

RE: The IETF Mission

[Ayyasamy, Senthilkumar \(UMKC-Student\)]

>>   o If one is revisiting the old ideas, they will most likely prefer
>> mailing list archives (due to its descriptive nature) than RFC.
>
> Ummm, no. Most IETF mailing lists are pretty inaccessible to non-WG
> participants because no one ever summarizes ideas before WG last call.
 ...
> (note the recent discussion on end-to-end as the TCP
> research community realized that they weren't sure what was, and was
> not, TCP).
...
> Mailing list archives are an order of magnitude more difficult than 
> that (for the reasons previously stated).
 
so, RFCs too share the same problem (as per your reference to TCP 
related RFC issue.) we should be specific about what can be made 
into RFC; it should not also share the long process time associated 
with informational RFCs (e.g., area report series after every IETF 
meeting which summarize BOF results.)

Re: The IETF Mission

[Spencer Dawkins]

- Original Message - 
From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[EMAIL PROTECTED]>
To: "Bob Braden" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 19, 2004 1:42 AM
Subject: RE: The IETF Mission

> Let's now consider usability grounds. The "pet" idea RFC series
doesn't
> serve the purpose:
>
>   o If one is revisiting the old ideas, they will most likely prefer
> mailing list archives (due to its descriptive nature) than RFC.

Ummm, no. Most IETF mailing lists are pretty inaccessible to non-WG
participants because no one ever summarizes ideas before WG last call.
Some are more inaccessible because of posting volume levels. Some are
becoming more inaccessible because they don't restrict posting to
members and are filling their archives with spam. Professional
networking researchers might have time, but might not, and people
doing prior art searches for ideas that they've just been sued over
might make time, but if our mailing list archives continue to be our
institutional memory, we'll continue to suffer from Alzheimers (except
that we lose our minds first-in-first-out, while Alzheimers takes your
mind last-in-first-out).

It's not like people who weren't there can find things easily in the
RFC series (note the recent discussion on end-to-end as the TCP
research community realized that they weren't sure what was, and was
not, TCP). I-D draft respositories are an order of magnitude more
difficult to search, because ideas come, go, and come again in the
lifetime of discussion of a draft (and because, sadly, we rename
drafts for almost no reason when they are adopted as WG items, and
gratuitously challenge people to associate individual draft history
with WG draft history). Mailing list archives are an order of
magnitude more difficult than that (for the reasons previously
stated).

Spencer

RE: The IETF Mission

[Ayyasamy, Senthilkumar \(UMKC-Student\)]

> let's consciously endeavor to ensure that sigificant non-standards 
> documents -- responsible position papers, white papers, new ideas, 
> etc.  -- become RFCs. 
 
i.e. something like IPng white paper series? 
 
On considering the feasibility ground, it is hard to standardize all
possible pet ideas into RFC series - due to scalability and hard-to-
reach-consensus reasons. For example, multi6 is discussing indirection
related proposals. The solutions ranges from minor configuration 
change to new layer. So, the task is really hard. At times, it will
make the WG task difficult (lack of focus etc.) OTOH, IRTF and new 
area related ideas should be made into RFC (as many have restricted 
mailing lists.)
 
Let's now consider usability grounds. The "pet" idea RFC series doesn't
serve the purpose:
 
  o If one is revisiting the old ideas, they will most likely prefer 
mailing list archives (due to its descriptive nature) than RFC. 
 
  o As for citation purpose, position/opinion papers can be in any 
form(RFC/mailing list post/expired ID/unpublished piece/even
personal communication.) OTOH, vendors/operators value IETF 
rubber stamp in the form of RFC for implementation/operational
practice.  

Re: The IETF Mission

[Paul Vixie]

> Having your idea published isn't equivalent to having your idea heard.

of course not.  most new documents in any series are ignored.  very few
people other than professional propeller-heads in ivory tower actually
read every article in acm-sigcomm or every rfc that comes out or whatever.
(computing systems, and the usenix proceedings, are notable exceptions,
with many hundreds of interested readers who at least skim everything
since it's likely that they know most of the program committee personally.)

> At least for well-known refereed forums, one can make the guess that
> "maybe an ACM or IEEE or whatever has relevant publications".
> Self-publication is dependent on getting a good Google ranking (more or
> less).

two things.  (1) people who want a reference will use google first, and
will search it thouroughly, before checking to see if acm or usenix or
ieee knows something that google hasn't heard yet.  (2) all publication
is dependent on promotion, whether the journal is refereed or whether
it's just up on the company web server.

so if you want to know that your pubs are available to interested parties,
put them where google can find them and you're done.  and if you want to
know that your pubs are skimmed by not-yet-interested parties, talk about
them in public and hope you motivate some lurkers.  (it's sort of like spam
in that way, though i wouldn't recommend trying to get a credit card number
before you show someone your content if you're using a list like ietf@ to
generate interest.)
-- 
Paul Vixie

Re: The IETF Mission

[Valdis . Kletnieks]

On Mon, 19 Jan 2004 04:13:48 GMT, Paul Vixie <[EMAIL PROTECTED]>  said:

> independent (non-series) document, then havn't we achieved gutenberg's goal,
> doesn't everybody have their own printing press, and can't we either choose
> an existing refereed forum for non-standards work, or just self-publish it?

Having your idea published isn't equivalent to having your idea heard.

At least for well-known refereed forums, one can make the guess that "maybe
an ACM or IEEE or whatever has relevant publications".  Self-publication is
dependent on getting a good Google ranking (more or less).



pgp0.pgp
Description: PGP signature

Re: The IETF Mission

[Spencer Dawkins]

- Original Message - 
From: "grenville armitage" <[EMAIL PROTECTED]>
To: "IETF Discussion" <[EMAIL PROTECTED]>
Sent: Sunday, January 18, 2004 4:17 PM
Subject: Re: The IETF Mission


> Is the standard for Informational currently that onerous?

I'm curious what the average time-to-publish from first draft to RFC
for Informational RFCs is. And that would be a very interesting
statistic for this discussion.

Spencer

Re: The IETF Mission

[Paul Vixie]

> ... Another way of looking at this would be to create some sort of
> refereed track.

Quis custodiet ipsos custodes?  (who shall govern the referees?)  note that
for a long time, peter salus begged the Computing Systems readership for
articles, and usenix ultimately closed it down due to lack of submissions.
i'm really not sure another refereed document series could find traction in
a world that already has an rfc editor, usenix, sigcomm, and so on.

> By the way, I think we should also ask where our role ends and where the 
> role of SIGCOMM and the like pick up (he says trying to pay his dues ;-).

while we at isc are hardly referees, i note with interest that one of the
publications at www.isc.org/tn was written by someone whose day job is
elsewhere, but he thought that "isc technote" was the logical place to put
this work, and we agreed.  with that remark i do not imply a solicitation,
but if isc and icann-secsac can each do their own document series, and if
the root name servers can publish c.root-servers.org/october21.txt as an
independent (non-series) document, then havn't we achieved gutenberg's goal,
doesn't everybody have their own printing press, and can't we either choose
an existing refereed forum for non-standards work, or just self-publish it?
-- 
Paul Vixie

Re: The IETF Mission

[Eliot Lear]

Bob,

I agree that many works of great value can be found in early RFCs.  But 
here's my question to you: if the focus is too much on standards, how do 
 we scale the process so that we can have great works that are NOT 
standards?  Clearly neither the IESG nor the IETF need be involved in 
that process, so long as the work does not misrepresent itself as a 
standard or other IETF-type work.

Now, you may say that the RFC Editor should take that job.  Okay.  Then 
I presume we need to scale the RFC Editor to this sort of task.  Another 
way of looking at this would be to create some sort of refereed track. 
That would be fine, but then it seems to me that the day of ASCII has to 
really come to an end (IMHO). (and with the mention of ASCII, why do I 
feel as though I've just violated Godwin's Law?)

By the way, I think we should also ask where our role ends and where the 
role of SIGCOMM and the like pick up (he says trying to pay his dues ;-).

Eliot

  *> 
  *> 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)
  *> 

Fred,

Please note that these references are to published RFCs, which are
available in perpetuity in the official document archive of the
Internet community, the RFC series.  It is an illustration that
publishing significant white papers and discussion papers as RFCs has
real value, which is being lost lost in what you correctly characterize
as an over-emphasis on "standards".  We are letting the marketing types
rule.
  *> 
  *> 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. 

Yes. So let's consciously endeavor to ensure that sigificant
non-standards documents -- responsible position papers, white papers,
new ideas, etc.  -- become RFCs.  (Making Internet Drafts into an
archival series seems like a terrible idea to me, but that is a
different topic.)
Bob Braden

Re: The IETF Mission [Re: Summary status of change efforts - Updated Web page]

[jfcm]

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

Re: The IETF Mission

[grenville armitage]

Iljitsch van Beijnum wrote:
> 
> On 18-jan-04, at 23:17, grenville armitage wrote:
[.]
> > If it is important, it'll progress the work of some group in the
> > IETF and be archived as an RFC.
> 
> Really. What's the number for the GSE RFC again? Even current work such
> as draft-ietf-idr-as4bytes-07.txt stays in draft limbo for years.

I suspect this speaks more to the focus of the authors of those documents
than any particular lack in the I-D development process. IMO, of course :)

[..]
> > Yes, that's a major problem. Organizations need to clean out their
> > clutter on a regular basis just like individuals do.
> 
> This argument is bogus as long as mailing list archives for stuff like
> draft announcements are kept.

I don't quite see it that way. A mail list archive quite clearly conveys
the sense of "this is a snapshot in time of things in the past" whereas our
I-D repository has/had the semantics of "this is current thinking of someone,
somewhere in the IETF" (for current <= 6 months). So I believe in mail
archives far more than I believe in permanent I-D archives.

[..]
> Searching in such an archive is only possible if you know the search
> terms in advance. For instance, the draft I mentioned earlier isn't
> easily found when searching for "32 bit as number".

I can't see how this would be improved by storing I-Ds in a well know,
permanent location. You'd still have trouble searching inside the archive
on ambiguous search terms.

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

Re: The IETF Mission

[Iljitsch van Beijnum]

On 18-jan-04, at 23:17, grenville armitage wrote:

Actually it's pretty much the same topic, as there needs to be a way 
to
preserve drafts that are important in some way or another.

If it is important, it'll progress the work of some group in the
IETF and be archived as an RFC.
Really. What's the number for the GSE RFC again? Even current work such 
as draft-ietf-idr-as4bytes-07.txt stays in draft limbo for years.

If it (the I-D) doesn't capture work
well enough to be archived as an RFC then it ought to fade from IETF
I-D storage.
I agree it would be nice if things worked this way but they don't.

If the authors (or someone else) feels strongly that there's
still material in their I-D of value, 'archiving' it on a personal 
website
for google to find.
Again, this simply doesn't work well enough in practice. Very little 
web content stays in the same place for many years, and for a variety 
of reasons, some things can be incredibly hard to search for in search 
engines.

One way to
do this would be to make all drafts that are worth preserving an RFC.
This means drastically lowering the standards for what can be 
published
as an RFC.

Is the standard for Informational currently that onerous?
I guess I'll have to find out...

Another way to do it would be to simply archive all
drafts. I agree this has the unpleasant side effect that all those
drafts that become obsolete (or are so from inception) stay around
forever.

Yes, that's a major problem. Organizations need to clean out their
clutter on a regular basis just like individuals do.
This argument is bogus as long as mailing list archives for stuff like 
draft announcements are kept.

Then perhaps we encourage WG members to post a summary of their non-RFC
ideas to the WG mailing list around the time when work is wrapping up.
The ideas will thus survive (to be found through Google) as long as 
the mailing list archive is around.
Searching in such an archive is only possible if you know the search 
terms in advance. For instance, the draft I mentioned earlier isn't 
easily found when searching for "32 bit as number".

Re: The IETF Mission

[grenville armitage]

Iljitsch van Beijnum wrote:
> 
[..]
> Actually it's pretty much the same topic, as there needs to be a way to
> preserve drafts that are important in some way or another.

If it is important, it'll progress the work of some group in the
IETF and be archived as an RFC. If it (the I-D) doesn't capture work
well enough to be archived as an RFC then it ought to fade from IETF
I-D storage. If the authors (or someone else) feels strongly that there's
still material in their I-D of value, 'archiving' it on a personal website
for google to find.

Or put differently, it is important for the IETF's collective clarity of
focus that IETF-hosted I-Ds decay and disappear if not actively maintained.
Whether or not an interested 3rd party (or I-D authors) maintain their I-Ds
beyond the expiration date is a separate issue.

> One way to
> do this would be to make all drafts that are worth preserving an RFC.
> This means drastically lowering the standards for what can be published
> as an RFC.

Is the standard for Informational currently that onerous?

> Another way to do it would be to simply archive all
> drafts. I agree this has the unpleasant side effect that all those
> drafts that become obsolete (or are so from inception) stay around
> forever.

Yes, that's a major problem. Organizations need to clean out their
clutter on a regular basis just like individuals do.

> But it's still better than the current situation, where making
> something an RFC means an incredible amount of work for many people,
> but not doing it means that ideas that may have taken days or weeks to
> write down are pretty much lost forever. Even the emails announcing the
> availability of new drafts are archived longer.

Then perhaps we encourage WG members to post a summary of their non-RFC
ideas to the WG mailing list around the time when work is wrapping up.
The ideas will thus survive (to be found through Google) as long as the mailing
list archive is around. If the author wants something longer lived, there's always
personal websites.

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

Re: The IETF Mission

[Valdis . Kletnieks]

On Sun, 18 Jan 2004 10:39:51 PST, Bob Braden said:

> Yes. So let's consciously endeavor to ensure that sigificant
> non-standards documents -- responsible position papers, white papers,
> new ideas, etc.  -- become RFCs.  (Making Internet Drafts into an
> archival series seems like a terrible idea to me, but that is a
> different topic.)

Out of curiosity, where would the I-D that described Mail-Followup-To: fall in
this spectrum?  This is an example of something that's widely deployed(*), and
definitely not a "non-standard", but we (for whatever reason) never got an RFC
out the door.

There's been other good ideas, or reasonable starts at same, that have expired
out of the I-D directory and never been published.  And unfortunately for the
person doing the literature review, this is a big problem, because the drafts
that *aren't* published are an important resource for ideas, both good and bad.
Yes, you still get to dig for which of the two it was, but in either case, finding
that the same (or similar idea) has been proposed before can be important... 

(*) So far this year, I've received 598 pieces of mail with one, out of 9,017
mails I saved the headers for (which included all the spam I've seen so far).
So in at least some communities, it's being used by a significant percentage of
users.  Compare to 559 for multipart/signed, for which (a) there *is* an RFC
and (b) 150 of which were my own postings to mailing lists...



pgp0.pgp
Description: PGP signature

Re: The IETF Mission

[Iljitsch van Beijnum]

On 18-jan-04, at 19:39, Bob Braden wrote:

So let's consciously endeavor to ensure that sigificant
non-standards documents -- responsible position papers, white papers,
new ideas, etc.  -- become RFCs.
Sigh. Even more RFCs. Pretty soon we're going to need a 32-bit RFC 
number space.

(Making Internet Drafts into an archival series seems like a terrible 
idea to me, but that is a different topic.)
Actually it's pretty much the same topic, as there needs to be a way to 
preserve drafts that are important in some way or another. One way to 
do this would be to make all drafts that are worth preserving an RFC. 
This means drastically lowering the standards for what can be published 
as an RFC. (Note that this brings us closer to what RFCs used to be 15 
years or so ago.) Another way to do it would be to simply archive all 
drafts. I agree this has the unpleasant side effect that all those 
drafts that become obsolete (or are so from inception) stay around 
forever. But it's still better than the current situation, where making 
something an RFC means an incredible amount of work for many people, 
but not doing it means that ideas that may have taken days or weeks to 
write down are pretty much lost forever. Even the emails announcing the 
availability of new drafts are archived longer.

I think there is some middle ground where expired drafts that are 
referred to in non-expired drafts are kept, as well as any drafts that 
are implemented and possibly drafts that a certain n number of people 
feel are interesting in some way.

RE: The IETF Mission

[Bob Hinden]

At 11:50 AM 1/18/2004, Christian Huitema wrote:

> Yes. So let's consciously endeavor to ensure that sigificant
> non-standards documents -- responsible position papers, white papers,
> new ideas, etc.  -- become RFCs.  (Making Internet Drafts into an
> archival series seems like a terrible idea to me, but that is a
> different topic.)
I could not agree more!
Obviously, we need some amount of peer review before a "white paper
draft" becomes a "white paper RFC", but I guess we know how to do that.
I agree with this as well.  I think it is important to keep the RFC series 
available for significant non-standards documents and IETF standards.

Bob

RE: The IETF Mission

[Christian Huitema]

> Yes. So let's consciously endeavor to ensure that sigificant
> non-standards documents -- responsible position papers, white papers,
> new ideas, etc.  -- become RFCs.  (Making Internet Drafts into an
> archival series seems like a terrible idea to me, but that is a
> different topic.)

I could not agree more!
Obviously, we need some amount of peer review before a "white paper
draft" becomes a "white paper RFC", but I guess we know how to do that.

-- Christian Huitema

Re: The IETF Mission

[Bob Braden]

  *> 
  *> 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)
  *> 

Fred,

Please note that these references are to published RFCs, which are
available in perpetuity in the official document archive of the
Internet community, the RFC series.  It is an illustration that
publishing significant white papers and discussion papers as RFCs has
real value, which is being lost lost in what you correctly characterize
as an over-emphasis on "standards".  We are letting the marketing types
rule.

  *> 
  *> 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. 


Yes. So let's consciously endeavor to ensure that sigificant
non-standards documents -- responsible position papers, white papers,
new ideas, etc.  -- become RFCs.  (Making Internet Drafts into an
archival series seems like a terrible idea to me, but that is a
different topic.)

Bob Braden

Re: The IETF Mission [Re: Summary status of change efforts - UpdatedWeb page]

[Pekka Savola]

On Sun, 18 Jan 2004, grenville armitage wrote:
> 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.

> Pekka Savola wrote:
>   [..]
> >  - 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 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.

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. ]]

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

Re: The IETF Mission [Re: Summary status of change efforts - Updated Web page]

[Pekka Savola]

Hi,

On Sat, 17 Jan 2004, Fred Baker wrote:
> At 04:26 AM 1/17/2004, Pekka Savola wrote:
> >"The purpose of the IETF is to create high quality, relevant, and
> >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."
[...]

I pretty much agree with all you're stating -- thanks for spelling it 
out.

> 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.

Right on.  This is the core of relevant, high-quality work I think.  
You could capture of some of those issues in the standards themselves,
if you really wanted, but a longer and more in-depth discussion seems
to belong in some other form of documents.

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

Re: The IETF Mission [Re: Summary status of change efforts - UpdatedWeb page]

[grenville armitage]

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

Pekka Savola wrote:
[..]
>  - 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 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.

[..]
> 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.

"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" 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?

"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.

Re: The IETF Mission [Re: Summary status of change efforts - Updated Web page]

[Fred Baker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At 04:26 AM 1/17/2004, Pekka Savola wrote:
>"The purpose of the IETF is to create high quality, relevant, and
>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. 
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 7.0.3 for non-commercial use 

iQA/AwUBQAnERm4xHWxyLJtDEQJOBACg6gngigXoA5jexovqdRHLbe1ELCYAnAgS
AYYF5UNWFVRChpzlkjUY1gXa
=Qa0x
-END PGP SIGNATURE-

The IETF Mission

[John Leslie]

Pekka Savola <[EMAIL PROTECTED]> wrote:
> 
> 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?  

   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 PROTECTED]>

The IETF Mission [Re: Summary status of change efforts - Updated Web page]

[Pekka Savola]

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 

RE: IESG proposed statement on the IETF mission

[john . loughney]

Harald,

>
> > I almost feel that this should just be dropped from the statement.  My
> > reasons being that I have been told by the IESG about protocol
> > extensibility is that the IETF wants to have a tighter control over protocol
> > extensibility, even for extensions thought to be for limited use
> > or specific networks (for example, cellular networks).  The reason
> > being is that once something is out there, it often starts to be used
> > in ways which were not originally planned or used outside of its
> > original 'limited use' plans.  Therefore, in order to ensure proper
> > protocol behavior & interoperability, the IESG wants to manage
> > extensibility.  This has been very true in SIP & Diameter, 
> > for example.
> 
> True. Nearly a year ago, we attempted to publish 
> draft-iesg-vendor-extensions, to describe these problems in more detail - 
> but we failed to get that finished.

So, I think we have to be careful about what we consider part of
the IETF mission, if we cannot get basic agreement upon the implications
of the mission statement.

> > On the other hand, we see a protocol like RADIUS, which the IETF
> > has never done a good job at working with or standardizing, being
> > developed in 4 or more SDOs, and not in a colaborative manner.  This
> > makes a big mess with the RADIUS spec, and RADIUS does seem like a
> > protocol that has a big effect on the Internet.
> 
> You'll have no disagreement from me that RADIUS is a problem!
> 
> > So, in summary, the IESG has shown not to follow the above paragraph,
> > sometimes even for good reasons.  I can't think of a way in which
> > modify the paragraph to make it any better - because there will always
> > be examples of work that the IETF choses to standardize (or not)
> > which will violate that part of the mission.  Perhaps moving the
> > 'for the internet to the previous paragraph is what is needed.
> 
> as I've said before - I don't think we can come up with a mission statement 
> that retroactively blesses everything we've done well before, or 
> retroactively curses everything we've done badly. And we do require 
> flexibility to "do what's right". But without the ability to talk about 
> what the mission of the IETF ... I think we'll do badly.

The past is the past, I don't want to revisit the past.  What I want
to do is to look forward.  We should have flexibility in terms of
how to decide what the IETF can do, what it can't do and what it
should (or shouldn't do).  I think we cannot make a blanket statement
in the mission that covers this.

thanks,
John

Re: IESG proposed statement on the IETF mission

[todd glassey]

Harald - I would agree that you are right here that the IETF's mission
process and in fact operations have fluttered in the breeze but the breeze
was caused by whoever was chair at the time's running by or away from the
key issue that they as the chair were given the ability because of a very
weak charter and very ambiguous processes (may instead of must everywhere)
create whatever it is they wanted. The issue is that the wants and mandates
of the chair's have changed over the years and so the IETF has changed in
response to that.


What that tends to indicate is that the IETF is responsive to changes in its
management's desires but not in the proletariat's... So then what I suggest
is the answer is a more rigidized standards process and in particular a set
of unambiguous policies and procedures that are at least modeled if not
tested before being released. And that are in and of themselves the same for
all they are applied to or around.

Todd Glassey
- Original Message - 
From: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Sunday, October 26, 2003 9:44 PM
Subject: RE: IESG proposed statement on the IETF mission


>
>
> --On 24. oktober 2003 18:07 +0300 [EMAIL PROTECTED] wrote:
>
> > Hi Harald,
> >
> > I'm going to pick on one statement, which other have as well.
> >
> >> 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.
> >
> > I almost feel that this should just be dropped from the statement.  My
> > reasons being that I have been told by the IESG about protocol
> > extensibility is that the IETF wants to have a tighter control over
> > protocol
> > extensibility, even for extensions thought to be for limited use
> > or specific networks (for example, cellular networks).  The reason
> > being is that once something is out there, it often starts to be used
> > in ways which were not originally planned or used outside of its
> > original 'limited use' plans.  Therefore, in order to ensure proper
> > protocol behavior & interoperability, the IESG wants to manage
> > extensibility.  This has been very true in SIP & Diameter, for example.
>
> True. Nearly a year ago, we attempted to publish
> draft-iesg-vendor-extensions, to describe these problems in more detail -
> but we failed to get that finished.
> >
> > On the other hand, we see a protocol like RADIUS, which the IETF
> > has never done a good job at working with or standardizing, being
> > developed in 4 or more SDOs, and not in a colaborative manner.  This
> > makes a big mess with the RADIUS spec, and RADIUS does seem like a
> > protocol that has a big effect on the Internet.
>
> You'll have no disagreement from me that RADIUS is a problem!
>
> > So, in summary, the IESG has shown not to follow the above paragraph,
> > sometimes even for good reasons.  I can't think of a way in which
> > modify the paragraph to make it any better - because there will always
> > be examples of work that the IETF choses to standardize (or not)
> > which will violate that part of the mission.  Perhaps moving the
> > 'for the internet to the previous paragraph is what is needed.
>
> as I've said before - I don't think we can come up with a mission
statement
> that retroactively blesses everything we've done well before, or
> retroactively curses everything we've done badly. And we do require
> flexibility to "do what's right". But without the ability to talk about
> what the mission of the IETF ... I think we'll do badly.
>
>Harald
>
>

Re: IESG proposed statement on the IETF mission

[Spencer Dawkins]

- Original Message - 
From: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>
>
> True. Nearly a year ago, we attempted to publish
> draft-iesg-vendor-extensions, to describe these problems in more
detail -
> but we failed to get that finished.

I should probably get out more, but I wasn't familiar with this draft.
I see that version 00 was announced. It looks to have been discussed
in a couple of posts on ccamp (and mpls? but I didn't look), and
revectored onto the main IETF discussion list, where it was the
subject of two posts. The draft says "The initial version of this
document was put together by the IESG", suggesting that they were
asking for input or other forms of help, but that didn't happen.

(In your opinion:) Was this a case of insufficient agreement, or a
case of insufficient cycles? Or something else?

Spencer

RE: IESG proposed statement on the IETF mission

[Harald Tveit Alvestrand]

--On 24. oktober 2003 18:07 +0300 [EMAIL PROTECTED] wrote:

Hi Harald,

I'm going to pick on one statement, which other have as well.

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.
I almost feel that this should just be dropped from the statement.  My
reasons being that I have been told by the IESG about protocol
extensibility is that the IETF wants to have a tighter control over
protocol
extensibility, even for extensions thought to be for limited use
or specific networks (for example, cellular networks).  The reason
being is that once something is out there, it often starts to be used
in ways which were not originally planned or used outside of its
original 'limited use' plans.  Therefore, in order to ensure proper
protocol behavior & interoperability, the IESG wants to manage
extensibility.  This has been very true in SIP & Diameter, for example.
True. Nearly a year ago, we attempted to publish 
draft-iesg-vendor-extensions, to describe these problems in more detail - 
but we failed to get that finished.
On the other hand, we see a protocol like RADIUS, which the IETF
has never done a good job at working with or standardizing, being
developed in 4 or more SDOs, and not in a colaborative manner.  This
makes a big mess with the RADIUS spec, and RADIUS does seem like a
protocol that has a big effect on the Internet.
You'll have no disagreement from me that RADIUS is a problem!

So, in summary, the IESG has shown not to follow the above paragraph,
sometimes even for good reasons.  I can't think of a way in which
modify the paragraph to make it any better - because there will always
be examples of work that the IETF choses to standardize (or not)
which will violate that part of the mission.  Perhaps moving the
'for the internet to the previous paragraph is what is needed.
as I've said before - I don't think we can come up with a mission statement 
that retroactively blesses everything we've done well before, or 
retroactively curses everything we've done badly. And we do require 
flexibility to "do what's right". But without the ability to talk about 
what the mission of the IETF ... I think we'll do badly.

  Harald

RE: IESG proposed statement on the IETF mission

[john . loughney]

Hi Harald,

I'm going to pick on one statement, which other have as well.

> 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.

I almost feel that this should just be dropped from the statement.  My
reasons being that I have been told by the IESG about protocol extensibility
is that the IETF wants to have a tighter control over protocol 
extensibility, even for extensions thought to be for limited use
or specific networks (for example, cellular networks).  The reason
being is that once something is out there, it often starts to be used
in ways which were not originally planned or used outside of its 
original 'limited use' plans.  Therefore, in order to ensure proper
protocol behavior & interoperability, the IESG wants to manage
extensibility.  This has been very true in SIP & Diameter, for example.

On the other hand, we see a protocol like RADIUS, which the IETF
has never done a good job at working with or standardizing, being
developed in 4 or more SDOs, and not in a colaborative manner.  This
makes a big mess with the RADIUS spec, and RADIUS does seem like a
protocol that has a big effect on the Internet.

So, in summary, the IESG has shown not to follow the above paragraph,
sometimes even for good reasons.  I can't think of a way in which 
modify the paragraph to make it any better - because there will always
be examples of work that the IETF choses to standardize (or not)
which will violate that part of the mission.  Perhaps moving the 
'for the internet to the previous paragraph is what is needed.

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

John

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


> "Harald" == Harald Tveit Alvestrand <[EMAIL PROTECTED]> writes:
Harald> In the discussions leading up to this document, we actually had 3
Harald> different other levels of "inclusivity" up for consideration:

  okay, I very much like these descriptions.

Harald> - "Everything that runs over the Internet is appropriate for IETF
Harald> standardization". 

Harald> - "Everything that needs open, documented interoperability and
Harald> runs over the Internet is appropriate for IETF
Harald> standardization". 

Harald> - "Everything that builds infrastructures on the Internet that
Harald> needs to be open and interoperable is appropriate for IETF
Harald> standardization". 

  These are three levels that I understand, and each seems to enclose
the next.

Harald> - "Everything that can seriously impact the Internet is
Harald> appropriate for IETF standardization". 

  This is very much more nebulous, because "seriously impact" is a question
of very open judgement.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP5g84oqHRg3pndX9AQH01AP/ayMZ2WJVxz7xZXVSu9Pbew9U1A+GLUFb
PVgK45qNL/qsL95U4cU1SyV5Tn2YYTjWkSD4j8tVNHAX+HyoqDJPYgWFwevOKblY
HCwUj3N6Y/U43TpIZ8+w8NqcIkV0Z4BPc9kjpSjiUeTOZ4nfY+Pbg3yS+vaUvWcd
ThqgtWgB7Lc=
=p3P3
-END PGP SIGNATURE-

Re: IESG proposed statement on the IETF mission

[Scott W Brim]

On Wed, Oct 15, 2003 01:01:53PM -0400, [EMAIL PROTECTED] allegedly wrote:
> 
> Hi Scott,
> 
> > Similarly for almost all of the rest.  What's the point?  Are you
> > reiterating the problem-statement work?  They're doing all right,
> > although perhaps you could help push the work to completion.  It would
> > be much more useful for you to reaffirm the fundamental 
> > principles that are not on the auction block.
> 
> >From your perspective, what are those fundamental principles?

I still haven't replied and I don't know when I'll get to.  I thought I
would have room in the last few days, but we're trying to finish a
document and my wife goes for her (hopefully final) chemotherapy session
on Thursday, which means I turn into a pumpkin for the rest of the week.
Someday.  Sorry.

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Spencer Dawkins]

 > The number of application protocols with the oomph to "break" the
> Internet is quite small

OK, I've gotta ask - how many times do we break the Internet before we
reverse this reasoning? (How many times is "too many"?)

(signed) curious

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Keith Moore]

> The number of application protocols with the oomph to "break" the 
> Internet is quite small

however, it's not safe to assume that it's zero.  any new killer app that were
poorly designed could do it.

also, you might be underestimating the damage done by HTTP (1.0 or later).

Re: IESG proposed statement on the IETF mission

[Dean Anderson]

> So yes Dean, I think you elude to the central issue - what is the common
> interest, and as the community was propelled almost forceably, and
> inexorably by market forces from a world where as Randy put it
> "operators cooperated" together, in a non-commercial endeavor based on
> very non-commercial values, into a very commercial world, did the
> community ever have a chance to take a big breath, inspect what has
> happened, and where it really wants to go from here.

Ok, here is MY opinion on the central issue:

Deployed communications systems are either military or commercial. Pure
research doesn't deploy systems.  OC-192 equipment and millions of miles
of fiber aren't cheap. Those complaining about how great things were when
they were non-commercial were preceeded by people complaining about
working for the military.

The people who don't want to service the commercial sector, and don't want
to service the military sector, really don't realistically have much of a
place in our society outside of pure research, and shouldn't be given
control over the future commercial or military applications of the
internet.

But it comes down to a question of whether science serves public policy or
whether public policy serves science. Which is the tail, and which is the
dog?  There is room for some pure science for nothing other than the sake
of pure science, but most of the research has to be done for productive
commercial or military purposes. I think this is a pretty general
statement that is as true of biotech research as it is of communications
research.  And since the internet is now vastly commercial, and
international, the leaders of the IETF ought to focus research on things
that will be commercially useful.

The present situation, in my opinion, the tail is wagging the dog.  This
should be changed.  The IETF mission should make clear what the
constituencies are, what the goals are, and what the priorities are, so
that the tail does the wagging.

It used to be that engineering and operations within a company "cooperated
together", sharing work and, of course, passwords. In small companies,
this is still be true.  But in many large telecom companies, engineering
is denied access to the production systems, and only the operations staff
can make changes.  This is necessary to ensure commercial stability, since
custom engineering changes don't scale well, and don't lead to widely
stable systems, since the custom changes may not be made on all systems.

Large groups work at arms length, even within a company, with well defined
protocols and policies regarding who can do what. Of course, there are
inevitable disagreements between engineering, operations, sales, etc.
These are resolved civilly, within the organization, and may include
appeals to senior management.  Those that know me, know that I'm usually
working in the engineering group, which means I am sometimes arguing with
the operations group for access to a newly deployed production system. The
first few times, I usually win. But I either have to stop asking or lose
these disgreements, in favor of documented troubleshooting procedures for
the benefit of improved stability. There are good reasons that practices
that might have been nice for small companies are abandoned by big
companies.  The IETF has this same issue.

Clearly, there are going to be even greater problems when many companies
come together to work on the same problems.  It is not reasonable to
expect that a few people can just "cooperate together" and work something
out for a large community.  What worked for the Internet many years ago
isn't going to work again--ever again--anymore than it would work for a
large telecom company to share passwords between engineering and
operations.

--Dean

Re: IESG proposed statement on the IETF mission

[mark seery]

Dean Anderson wrote:

On Thu, 16 Oct 2003, mark seery wrote:

 

Trust model
=
Inherent in Eric's problem statement is the notion that end systems have
the ability to impact the experience other Internet users have. Whether
this is the result of an historical trust model, where people using the
Internet were assumed to a) have clue and b) be acting in the best
interests of the community, or whether this is the result of other
community values, this diserves comment/debate, IMHO.
   

I've noticed that the people who claim to have the most clue, frequently
don't,
"...most imposters are desperate to prove that they are not what they 
are..." - Katherine Hepburn, Love Story

that said, no one has clue in everything, and in almost any one thing, 
there is almost always some one with more clue, so this too is relative.

and the people who claim most to be acting in the interests of the
community, aren't.
"Patriotism is the last refuge of a scoundrel."  - Samuel Johnson.

that said there is a lot that is instructive about listening to the 
ghosts from the past. lessons in open processes as an immutable value 
for example.

Clue has to do with being right, and time always reveals who and what is
right.  It is not always immediately apparent who is right. But the one
with the "clue" will be shown to have been right later on
But the assasination has usually taken place by then. The lesson of 
almost any complex society is dare to be different, and the gods will 
exact their revenge. It takes people of courage, stupidty or independent 
wealth to truly express what they think. That is why secret ballots 
exist in many democracies - it allows a broader range of non-stupid 
people to express their opinion (all beit on a narrow decision criteria).

Community has to do with democratic, common interests. It is always
interesting that the people who are most shrill about "the interests
community" often want to exclude most of the community from the decision.
Common interests I agree, which I think is probably the crux of the 
mission discussion. Whether a "statement" or any other single instrument 
is sufficient to cross this bridge is fair game for discussion. But 
undoubtely, IMHO, it is the definition, articulation, and recognition of 
what the common interest is that is the problem at hand. For example, I 
don't think IEEE 802.3 have any problems understanding what their common 
interest is - the propogation of Ethernet technology - with no qualms 
about the commercial realities of that common interest.

What is the common interest of the IETF? Packets to the people? The 
propogation and use of IP (including Eric's expression of migrating 
applications from other technologies)? The refinement and perfection of 
connectionless networking techology? The development/standardization of 
technologies that address as many networking problem spaces as possible 
forming an umbrella under which we can throw many things by calling it 
the "Internet"?

So yes Dean, I think you elude to the central issue - what is the common 
interest, and as the community was propelled almost forceably, and 
inexorably by market forces from a world where as Randy put it 
"operators cooperated" together, in a non-commercial endeavor based on 
very non-commercial values, into a very commercial world, did the 
community ever have a chance to take a big breath, inspect what has 
happened, and where it really wants to go from here.

Given the seeminly overloaded semantics of "mission" perhaps a statement 
of "common interest" would indeed be more beneficial.

As for the democratic bit, I have been giving a lot of thought recently 
to what a democracy is or should be - as such I am not sure what 
democratic is, so I leave that piece as an exercise to the reader.

Best,..

RE: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Harald Tveit Alvestrand]

Christian,

we might be looking through opposite ends of this tunnel.

--On 16. oktober 2003 15:15 -0700 Christian Huitema 
<[EMAIL PROTECTED]> wrote:

I think this point is one of the critical causes of conflict when
talking
about the IETF mission - and unless we lance the boil, actually talk
about
it, and attempt to *resolve* the issue, we will go on revisiting the
issue
forever, with nothing but wasted energy to show for it.
Well, to paraphrase a well known leader, "the IETF, how many divisions?"
The gist of this comment is that someone developing a network
application protocol ought to somehow get a blessing from the IETF.
Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for
that matter HTTP?
For application protocols, I view it in the opposite direction - if someone 
comes to the IETF and *asks* for the IETF's advice, blessing or ownership, 
what are the conditions under which we say "yes"? Or "no"?

For those that never ask, and never become important, I say "not my 
problem". The number of application protocols with the oomph to "break" the 
Internet is quite small - offhand, I'd say that HTTP/1.0 probably was the 
closest try.

If the Internet is so fragile that a poorly developed application can
break it, then the IETF response should not be to try control each
application. It has to be, design checks that can be implemented by
cooperating hosts and routers so that their neck of the Internet is in
good health!
Now there's an idea. :-)

The flipside is of course with those things that are *already* under IETF 
control, or critical for our infrastructure, for some reason. The 
abstracted version of the fights over MIME types, URI schemes, SIP 
extension etcetera seems to be "don't extend until you've talked to us 
about what you're doing, and if we don't like it, don't try to pretend that 
we did" (the P-headers, vnd. MIME types and the proposed faceted URI 
schemes); I'm not certain what the abstracted version of the fights over 
COPS, CR-LDP, RSVP-TE and so on are.

The IETF has got fewer divisions than the Pope, of course. Anyone is free 
to ignore us. And we need to remember that, sometimes.

Re: IESG proposed statement on the IETF mission

[Harald Tveit Alvestrand]

since both you and Scott pointed out this one

--On 15. oktober 2003 12:48 -0400 Keith Moore <[EMAIL PROTECTED]> wrote:

   "The purpose of the IETF is to create high quality, relevant,
and timely standards for the Internet."
I actually believe IETF has a somewhat wider purpose than that.  What
I usually say is "we're trying to help the Internet work better".
my personal belief is that the purpose of the *Internet technical 
community* is to make the Internet work better. But we have to admit to 
division of labor, and the part that we call the IETF needs to concentrate 
on standards, and the "supporting functions" of fora for experimentation 
and gathering of operational experience.

Others do the work of pulling fiber, designing routers, arresting spammers 
and detecting virii. We, gathered as the IETF, should not (IMHO) attempt to 
take over those functions. Despite the fact that it's what many of us do 
when we're not doing IETF stuff!

   Harald

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Harald Tveit Alvestrand]

--On 16. oktober 2003 13:15 -0400 Eric Rosen <[EMAIL PROTECTED]> wrote:

- "For the Internet" - only the stuff that is directly involved in
making  the Internet work is included in the IETF's scope.
In other words, routing,  DNS, and Internet operations/management.
Adopting this as  the IETF's mission  would be a  very radical change
indeed!
I erred in describing that category. I should have used something else - it 
was not what the IESG thought it was saying in its proposed mission 
statement, so me recycling the term "for the Internet" in the bulleted list 
I made added confusion rather than clarifying. Sorry!

(I still think it's a valid point on the scale. It leaves us with a much 
smaller IETF. But some people tend to think that's a positive side.)

  Harald

Re: IESG proposed statement on the IETF mission

[Dean Anderson]

On Thu, 16 Oct 2003, mark seery wrote:

> Trust model
> =
>
> Inherent in Eric's problem statement is the notion that end systems have
> the ability to impact the experience other Internet users have. Whether
> this is the result of an historical trust model, where people using the
> Internet were assumed to a) have clue and b) be acting in the best
> interests of the community, or whether this is the result of other
> community values, this diserves comment/debate, IMHO.

I've noticed that the people who claim to have the most clue, frequently
don't, and the people who claim most to be acting in the interests of the
community, aren't.

Clue has to do with being right, and time always reveals who and what is
right.  It is not always immediately apparent who is right. But the one
with the "clue" will be shown to have been right later on.

Community has to do with democratic, common interests. It is always
interesting that the people who are most shrill about "the interests
community" often want to exclude most of the community from the decision.

Therein lies the problem.

--Dean

RE: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Christian Huitema]

> > According to you, this has nothing to  do with the IETF.  It might
> result
> > in the congestive collapse of the Internet,  but who cares, the IETF
> > doesn't do street  lights.  I would  like  to see  the  criteria
which
> > determine  that telephones belong on the Internet but street lights
> don't!
> 
> thanks for making the most concise statement of the conflict here in
the
> discussion so far!
> I think this point is one of the critical causes of conflict when
talking
> about the IETF mission - and unless we lance the boil, actually talk
about
> it, and attempt to *resolve* the issue, we will go on revisiting the
issue
> forever, with nothing but wasted energy to show for it.

Well, to paraphrase a well known leader, "the IETF, how many divisions?"
The gist of this comment is that someone developing a network
application protocol ought to somehow get a blessing from the IETF.
Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for
that matter HTTP?

If the Internet is so fragile that a poorly developed application can
break it, then the IETF response should not be to try control each
application. It has to be, design checks that can be implemented by
cooperating hosts and routers so that their neck of the Internet is in
good health!

-- Christian Huitema

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Eliot Lear]

The example I'm thinking about involved predecessors to OpenGL. 
As this example  doesn't even involve communication over  a network, I would
agree that it is out of scope.   ...
[OpenGL example]
It's not that other examples such as X couldn't have used more network knowledge to
avoid problems (e.g. the mouse stuff), but that the network stuff is
the tail of that and many other dogs.  Because of my employement
history, I may know a little more about how to do graphics in general
or over IP networks than many IETF participants, but I know that I'm
abjectly completely utterly incompetent for doing exactly what the
IETF started to do in that case.
Great scope example.  The issue for OpenGL, however, demonstrates a gap 
in as much as the developers would probably have liked something like 
dccp so that they could use a library to get Nagle, backoff, etc.  While 
we're a wire protocol sort of a group, we all should realize the 
importance of generality and good library support ;-)


If "out of scope" were removed as an acceptable reason to not do things,
then you would never squelch bad efforts.
An effort isn't bad because it's out of scope.  An effort is bad because 
it's bad, and we invest our faith in the IESG that they will use good 
judgment to catch bad efforts.

If anyone on the IESG does not feel empowered to say "no" they should 
not be on the IESG.  WG chairs need to vet their own group's work first, 
of course.  And we could certainly do a better job on that.

Eliot

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[mark seery]

Scoping is certainly used successfully as an argument at the WG level, 
through the more common pronnouncement "that would require a change 
to the charter.." Scoping aids WGs in being able to move the ball 
forward in the direction of predfined goals, and hence is a process aid. 
This is scoping at a micro level. I would think that the role of mission 
is to provide scoping at a macro level, the kind of scoping that 
determines whether a WG is established in the first place or not.

More importantly I would suggest, the simple requirement for making 
binary decisions about whether something is in scope or not is necessary 
but not sufficient. An institution surely needs some way to guide its 
priorities as well. So one could for example agree with Eric's 
definition of what the IETF's mission is, but once that is done, what 
then guides the priorities of the IETF? I think you will find this to be 
at the heart of the debate:

scoping=>smaller workload=>focused differentiation in the standards 
marketplace+better quality output.

Every entity must decide what it is going to do uniquly better than any 
other entity. This is the purpose of mission. Generic catchall missions 
do not help entities keep the eye on that particular ball.

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Vernon Schryver]

> From: Eric Rosen <[EMAIL PROTECTED]>

> ...
> > Sheesh!--next you'll be telling us that you never heard the phrase
> > "out of scope" before last week. 
>
> Sure I have.  There's  hardly a piece of work done by  the IETF that someone
> hasn't claimed to  be out of scope.   It's just that the phrase  is not used
> consistently.  

That's true.

>If  we look at the  historical facts about the  work that the
> IETF has traditionally taken on, it's hard to draw any conclusion other than
> that anything  is in  scope which  promotes and facilitates  the use  of the
> Internet and of IP infrastructure.  And I think that's exactly what the IETF
> should be doing.

That's wrong.  At best it's meaningless.  For example it supports
lobbying Congress.


> > The example I'm thinking about involved predecessors to OpenGL. 
>
> As this example  doesn't even involve communication over  a network, I would
> agree that it is out of scope.   ...

It was out of scope, but not because it did not involve putting graphics
stuff over UDP or TCP, because it did.  My fellow employees in SGI's
network group and I breathed a sigh of releaf when Ron returned from
an IETF meeting to report that "out of scope" had carried the day
against other IETF participants who thought that knowing people who
knew about Nagle and congestion control and avoidance was enough to
design graphics remote procedure calls or similar.  It's not that
other examples such as X couldn't have used more network knowledge to
avoid problems (e.g. the mouse stuff), but that the network stuff is
the tail of that and many other dogs.  Because of my employement
history, I may know a little more about how to do graphics in general
or over IP networks than many IETF participants, but I know that I'm
abjectly completely utterly incompetent for doing exactly what the
IETF started to do in that case.


> > Often the brutal  WG chairs say they don't think the  WG knows enough, but
> > it's the scope arguments that carry the day. 
>
> I've never had  much luck myself with scope arguments,  unless they could be
> backed up with an argument either that the center of expertise is elsewhere,
> or that the topic has no bearing on IP.  Of course, people will sometimes be
> willing  to  agree  that  the  center  of  expertise  is  elsewhere  without
> necessarily agreeing that they themselves aren't experts ;-) Sometimes scope
> arguments are merely  face-saving ways of saying "we don't  know what we are
> doing".  Other times, scope arguments are merely "polite" ways of saying "we
> don't think  you know what  you are doing".   You almost never  hear someone
> saying "that sounds like a really  good idea, but unfortunately it is out of
> scope". 

Yes, with the proviso that you mean you usually don't hear people really
meaning that last sentence.  You certainly hear those words a lot.

If "out of scope" were removed as an acceptable reason to not do things,
then you would never squelch bad efforts.

I suspect the whole effort of defining IETF charters or missions is
a very bad idea.  It's often better to not spell things out, but to
rely on the good judgement of the people running the show.


Vernon Schryver[EMAIL PROTECTED]

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Eric Rosen]

> The gist of this comment is that someone developing a network
> application protocol ought to somehow get a blessing from the IETF. 
> Reality check. Who got the IETF approval to deploy ICQ, Kazaa, or for
> that matter HTTP? 

The fact  that someone  did something without  the IETF's approval  does not
imply that  what they did is  outside the scope of  the IETF, or  that it is
beyond the IETF's mission. 

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Eric Rosen]

> Sheesh!--next you'll be telling us that you never heard the phrase
> "out of scope" before last week. 

Sure I have.  There's  hardly a piece of work done by  the IETF that someone
hasn't claimed to  be out of scope.   It's just that the phrase  is not used
consistently.  If  we look at the  historical facts about the  work that the
IETF has traditionally taken on, it's hard to draw any conclusion other than
that anything  is in  scope which  promotes and facilitates  the use  of the
Internet and of IP infrastructure.  And I think that's exactly what the IETF
should be doing.

> The example I'm thinking about involved predecessors to OpenGL. 

As this example  doesn't even involve communication over  a network, I would
agree that it  is out of scope.   But that's a rather extreme  case, most of
the contentious areas do involve communications over an IP infrastructure.

> Often the brutal  WG chairs say they don't think the  WG knows enough, but
> it's the scope arguments that carry the day. 

I've never had  much luck myself with scope arguments,  unless they could be
backed up with an argument either that the center of expertise is elsewhere,
or that the topic has no bearing on IP.  Of course, people will sometimes be
willing  to  agree  that  the  center  of  expertise  is  elsewhere  without
necessarily agreeing that they themselves aren't experts ;-) Sometimes scope
arguments are merely  face-saving ways of saying "we don't  know what we are
doing".  Other times, scope arguments are merely "polite" ways of saying "we
don't think  you know what  you are doing".   You almost never  hear someone
saying "that sounds like a really  good idea, but unfortunately it is out of
scope". 

Re: IESG proposed statement on the IETF mission

[masataka ohta]

Simon Woodside;

Yes, and towards a possibly more contentious application, see Voice over 
IP. Lots of VoIP work is being done without involving the internet at 
all. Used by telecoms for telecoms applications, where "best effort" 
isn't good enough because it needs to keep working when the power goes 
out. IP, yes, Internet, no.
Why, do you think, the Internet may stop working when the power
goes out?
It should not, which is required to certain ISPs by regulation at
least in Japan.
Against that you have "voice over internet" which is AKA "voice chat" 
and already abounds in true internet p2p apps like iChat, GnomeMeeting, 
and some programs on that other OS. These run on the public internet and 
benefit from the IETF design paradigms like edge-to-edge (aka end2end) 
and best effort but also have to accept the relevant drawbacks.
"voice chat"? Are you assuming PCs?

POTS telephone devices and terminal adaptors is the natural way
of "voice over the Internet".
Note that end to end architecture means ultimate availability of
fate sharing.
		Masataka Ohta

PS

According to the end to end principle, end user equipments should
have their own power backup, of course, which is also the case with
ISDN TA or cellular phone devices. Then, with multihoming, your
connection is a lot more robust than that of a single telephone
company. 

Re: IESG proposed statement on the IETF mission

[Simon Woodside]

On Wednesday, October 15, 2003, at 12:57  PM, Eric Rosen wrote:


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

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.
Yes, and towards a possibly more contentious application, see Voice 
over IP. Lots of VoIP work is being done without involving the internet 
at all. Used by telecoms for telecoms applications, where "best effort" 
isn't good enough because it needs to keep working when the power goes 
out. IP, yes, Internet, no.

Against that you have "voice over internet" which is AKA "voice chat" 
and already abounds in true internet p2p apps like iChat, GnomeMeeting, 
and some programs on that other OS. These run on the public internet 
and benefit from the IETF design paradigms like edge-to-edge (aka 
end2end) and best effort but also have to accept the relevant drawbacks.

simon

Well, let's test this assertion.  Suppose a consortium of electric 
companies
develops a UDP-based protocol  for monitoring and controlling street 
lights.
It turns  out that  this protocol generates  an unbounded amount  of 
traffic
(say,  proportional to  the square  of the  number of  street lights  
in the
world), has no  congestion control, and no security, but  is expected 
to run
over the Internet.

According to you, this has nothing to  do with the IETF.  It might 
result in
the congestive collapse of the Internet,  but who cares, the IETF 
doesn't do
street  lights.  I would  like  to see  the  criteria  which determine 
 that
telephones belong on the Internet but street lights don't!

Another problem  with your  formulation is that  the Internet is  a 
growing,
changing, entity,  so "for the Internet"  often means "for what  I 
think the
Internet  should  be  in  a  few  years", and  this  is  then  a  
completely
unobjective criterion.  One  would hope instead that the  IETF would 
want to
encourage competition between different  views of Internet evolution, 
as the
competition of ideas is the way to make progress.

I also do not understand whether "for the Internet" means something 
different
than "for IP networking" or not.

I think  it should  also be part  of the  mission to produce  
standards that
facilitate the migration to IP  of applications and infrastructures 
that use
legacy networking  technologies.  Such  migration seems to  be good  
for the
Internet, but I don't know if it is "for the Internet" or not.


--
www.simonwoodside.com :: www.openict.net :: www.semacode.org
99% Devil, 1% Angel

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Vernon Schryver]

> From: Eric Rosen <[EMAIL PROTECTED]>

> > That is wrong or at least a gross overstatement. 
>
> If  that's  what  you think,  I  invite  you  to  make  a list  of  all  the
> IETF-standardized protocols and explain how  they are all (or even more than
> 50% of them) needed to make the Internet work.

There's a progression here:
  1. ad hoc network interoperability group forms.
  2. it has some success and gains some fame.
  3. it is besieged by people eager to borrow its printing press
  4. it is besieged by people who know everything about everything and
have a duty to write or at least control all standards on
everything including what people perversions do in the privacy
of their own networks.

I've been complaining about #3 for many years.  Examples of #4 include
some of the more vigorous combatants in the IPv6 site local arena
and the notion that notion that nothing is out of scope.


> > There have been many things that the IETF has chosen to step away from but
> > that  ran  and  run  over  the Internet.   Some  graphics  standards  come
> > immediately to my  mind ... Those graphics standards were  kept out of the
> > IETF not  because the  working groups involved  thought they  didn't think
> > they were experts, but because the subject was out of scope for the IETF." 
>
> I'm not  familiar with this particular  case, but I don't  see why protocols
> for distributing graphics would be thought  to fall outside the scope of the
> IETF, any more  than protocols for distributing voice  or video.  Of course,
> graphics standards  that have nothing  do with distribution of  the graphics
> over IP would be out of scope.

The example I'm thinking about involved predecessors to OpenGL.
People who know about network stuff know enough to stuff bits into
wires, but that's the earier part of things like OpenGL, Microsoft's
alternative whose name eludes me, JPEG, MPEG, and so forth.


> > No committee is ever able to limit itself on grounds of insufficient
> > expertise.  
>
> Now, there  is a  gross overstatement!  For  everyone who  proclaims himself
> (rightly or  wrongly) to be  an expert on  some topic, there are  always two
> other people who claim  that he is clueless. 

The other two base their claims on their own greater expertise and
wouldn't dream of suggesting that they are not well suited for
standardizing whatever it is.

>   It's not uncommon  for a WG to
> refuse  to  pick up  a  topic  because the  consensus  is  that the  topic's
> proponents are clueless.  

Please name an example of such a case.  I have seen WG chairs and
others use brute force and out-of-scope arguments to halt nonsense,
but I've never seen "we don't know enough" work.  Often the brutal WG
chairs say they don't think the WG knows enough, but it's the scope
arguments that carry the day.


Sheesh!--next you'll be telling us that you never heard the phrase
"out of scope" before last week.


Vernon Schryver[EMAIL PROTECTED]

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Eric Rosen]

> That is wrong or at least a gross overstatement. 

If  that's  what  you think,  I  invite  you  to  make  a list  of  all  the
IETF-standardized protocols and explain how  they are all (or even more than
50% of them) needed to make the Internet work.

> There have been many things that the IETF has chosen to step away from but
> that  ran  and  run  over  the Internet.   Some  graphics  standards  come
> immediately to my  mind ... Those graphics standards were  kept out of the
> IETF not  because the  working groups involved  thought they  didn't think
> they were experts, but because the subject was out of scope for the IETF." 

I'm not  familiar with this particular  case, but I don't  see why protocols
for distributing graphics would be thought  to fall outside the scope of the
IETF, any more  than protocols for distributing voice  or video.  Of course,
graphics standards  that have nothing  do with distribution of  the graphics
over IP would be out of scope.

> No committee is ever able to limit itself on grounds of insufficient
> expertise.  

Now, there  is a  gross overstatement!  For  everyone who  proclaims himself
(rightly or  wrongly) to be  an expert on  some topic, there are  always two
other people who claim  that he is clueless.  It's not uncommon  for a WG to
refuse  to  pick up  a  topic  because the  consensus  is  that the  topic's
proponents are clueless.  

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Vernon Schryver]

> From: Eric Rosen <[EMAIL PROTECTED]>

> > - "For the Internet" - only the stuff that is directly involved in making 
> > the Internet work is included in the IETF's scope. 
>
> In other words, routing,  DNS, and Internet operations/management.  Adopting
> this as  the IETF's mission  would be a  very radical change  indeed!  While
> this particular  mission statement does seem  to reflect the  interests of a
> certain notorious IESG member, let's not pretend that this has ever been the
> limit of the IETF's mission.  The IETF has always been concerned with things
> that make the Internet more useful,  and with things that expand the utility
> of the IP protocol suite.  There's never been a time when "for the Internet"
> was an accurate representation of the IETF's concerns.

That is wrong or at least a gross overstatement.

> ...
> The  formulation   I  like  is  "Everything  that   needs  open,  documented
> interoperability  and  runs  over  the  Internet  is  appropriate  for  IETF
> standardization".  This is  much truer to the IETF's  current and historical
> practice.  

That is also wrong or at least a gross overstatement.  There have been
many things that the IETF has chosen to step away from but that ran
and run over the Internet.  Some graphics standards come immediately
to my mind.

> That doesn't  necessarily mean that  the IETF has to  standardize everything
> that falls within  its mission.  For instance, a  particular area might fall
> within the mission, but the IETF  might not have the expertise to tackle it.
> A WG  in that area  could then be  rejected on the grounds  of "insufficient
> expertise".  Such decisions  would have to be made  on a case-by-case basis.
> Again, this is the way such decisions have always been made in the IETF.

No committee is ever able to limit itself on grounds of insufficient
expertise.  The people who join committees are predisposed to think
that they're sufficiently expert to deal with the subject matter.

Those graphics standards were kept out of the IETF not because the
working groups involved thought they didn't think they were experts,
but because the subject was out of scope for the IETF.  That most of
participants had no clues about computer graphics was incomprehensible
to most of the participants, and unfortunately irrelevant.


Vernon Schryver[EMAIL PROTECTED]

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Eric Rosen]

> - "For the Internet" - only the stuff that is directly involved in making 
> the Internet work is included in the IETF's scope. 

In other words, routing,  DNS, and Internet operations/management.  Adopting
this as  the IETF's mission  would be a  very radical change  indeed!  While
this particular  mission statement does seem  to reflect the  interests of a
certain notorious IESG member, let's not pretend that this has ever been the
limit of the IETF's mission.  The IETF has always been concerned with things
that make the Internet more useful,  and with things that expand the utility
of the IP protocol suite.  There's never been a time when "for the Internet"
was an accurate representation of the IETF's concerns.

You are  of course welcome  to propose such  a radical change to  the IETF's
mission.  But  if you are  going to circulate  a document under  the subject
line "IESG proposed statement on the IETF mission", you should make it clear
that the  IESG is proposing to make  a complete change in  the IETF mission.
Instead,  you  give  the impression  that  the  IESG  thinks that  "for  the
Internet" is and has always been the IETF's mission. 

The  formulation   I  like  is  "Everything  that   needs  open,  documented
interoperability  and  runs  over  the  Internet  is  appropriate  for  IETF
standardization".  This is  much truer to the IETF's  current and historical
practice.  

That doesn't  necessarily mean that  the IETF has to  standardize everything
that falls within  its mission.  For instance, a  particular area might fall
within the mission, but the IETF  might not have the expertise to tackle it.
A WG  in that area  could then be  rejected on the grounds  of "insufficient
expertise".  Such decisions  would have to be made  on a case-by-case basis.
Again, this is the way such decisions have always been made in the IETF.

Re: IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Bill Manning]

% --On 15. oktober 2003 12:57 -0400 Eric Rosen <[EMAIL PROTECTED]> wrote:
% 
% > Well, let's test this assertion.  Suppose a consortium of electric
% > companies develops a UDP-based protocol  for monitoring and controlling
% > street lights. It turns  out that  this protocol generates  an unbounded
% > amount  of traffic (say,  proportional to  the square  of the  number of
% > street lights  in the world), has no  congestion control, and no
% > security, but  is expected to run over the Internet.
% >
% > According to you, this has nothing to  do with the IETF.  It might result
% > in the congestive collapse of the Internet,  but who cares, the IETF
% > doesn't do street  lights.  I would  like  to see  the  criteria  which
% > determine  that telephones belong on the Internet but street lights don't!
% 
% thanks for making the most concise statement of the conflict here in the 
% discussion so far!
% I think this point is one of the critical causes of conflict when talking 
% about the IETF mission - and unless we lance the boil, actually talk about 
% it, and attempt to *resolve* the issue, we will go on revisiting the issue 
% forever, with nothing but wasted energy to show for it.
% 
% In the discussions leading up to this document, we actually had 3 different 
% other levels of "inclusivity" up for consideration:
% 
% - "Everything that runs over the Internet is appropriate for IETF 
% 
% - "Everything that needs open, documented interoperability and runs over 
% the Internet is appropriate for IETF 
% 
% - "Everything that builds infrastructures on the Internet that needs to be 
% open and interoperable is appropriate for IETF standardization". 
% 
% - "Everything that can seriously impact the Internet is appropriate for 
% IETF standardization". 

% - "For the Internet" - only the stuff that is directly involved in making 
% the Internet work is included in the IETF's scope.
% 
% a discussion argue based on "the mission of the IETF", with conflicting 
% definitions, is not the best thing for the Internet.
% 
%   Harald

I guess for me, I always thought that the IETF and its
precursors were interested in developing engineering 
solutions / designing protocols that would allow "end2end or
any2any" communications, regardless of underlying transport
media, be it seismic wave, avian carrier, radio waves or
the PSTN.  - At no time did I ever truly beleive that 
the systems that used these protocols/solutions would always
be on and fully connected.  Infrastructures that use IETF
products have nearly always been only partially connected
and many systems are not always on.

So while a design goal might have been to support always 
on/fully connected state, the reality is that infrastructres
have nearly always been disjoint/unconnected and endpoints
come and go.  But when they are connectable, they should 
function in a seamless, e2e fashion, at least IMHO.

And then you neglect an unstated presumption in the last 
two bullet points:  As perceived by who?  


--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

Re: IESG proposed statement on the IETF mission

[mark seery]

Harald.

Interesting, important, thanks.

Internet usage
==
One of the large dynamics not explicitly mentioned is the increased 
commercial usage/value of the Internet and how that drives the community 
in new directions.

Trust model
=
Inherent in Eric's problem statement is the notion that end systems have 
the ability to impact the experience other Internet users have. Whether 
this is the result of an historical trust model, where people using the 
Internet were assumed to a) have clue and b) be acting in the best 
interests of the community, or whether this is the result of other 
community values, this diserves comment/debate, IMHO.

The basic dynamic of course that needs to be balanced is the rights of 
Internet users, the role and obligations of operators, and the creative 
abuse of the network that could lead to unforseen new value and 
applications.

Discusion of trust models will inevitably also lead us down the road of 
discussing hairy issues such as (D)DOS - but isn't that one of the more 
pressing issues today?

Network Architecture & layers 1-9
=
Firstly, seems there are four basic functions that need addressing in 
the building of internets (remembering the network of networks value, 
there is not one "I"nternet):

-Transport of packets from one edge of an internet to the other edge 
(PE if u like, but...).
-Transport of packets from end system to end system over one of more 
internets
-Management and operation of internets
-Applications that make use of the above infrastructure

Based on the inclusivity problem statement positions you have 
considered, and other comments WRT how much the IETF can do, it would 
appear that over time the last bullet point above might become disjoint 
from the first three. Not arguing that application development should be 
done at the IETF, but I think that some recognition needs to be made of 
the vastly different skill sets and interests of end-system operators 
and engineers and infrastructure operators and engineers. Perhaps the 
"area" concept needs another super-layer, especially given the vast 
difference in communities of liasion.

Lastly, some discussion of layer 1-to-9 should take place. Seems to me 
the IETF works very well when focused at layers 3 to 4; has of course 
established many important application layer standards; but experiences 
challenging liasion when focusing below layer three (data/user plane) - 
PPP not withstanding. In the spirit of "we can not do everything", this 
is deserving of discussion if for no other reason than to clear the air 
as we move forward.

Perhaps one of the most important areas of focus is the connection of 
end systems and internets to other internets. This is an area that must 
allow for creative abuse of the network through both freedom of higher 
layer protocols and also the facilitation and participation of as many 
systems vendors as possible addressing cable, wireless, wireline,... 
This area should especially be supported by standards, implementation 
agreeements, and interoperability efforts.

The immutable vs the mutable
=
Seems like it would be useful to separate the immutable from the mutable.

Examples of immutable might be (not a prescription just examples):

-rough consensus
-running code
-Chairs that operate in the best interests of the community
-the UNIX-like adherence to development of small building blocks (also 
present in biology BTW).
-network of networks

Examples of the mutable might be:

-over the next 5 years we are going to focus on (D)DOS

Lancing the boil

There is nothing nice, pleasant, or enjoyable about lancing boils, but 
if we are to do so, then the starting point should be the encouragement 
of the identification of the largest boils.

IETF mission boundaries (Re: IESG proposed statement on the IETF mission )

[Harald Tveit Alvestrand]

Eric,

--On 15. oktober 2003 12:57 -0400 Eric Rosen <[EMAIL PROTECTED]> wrote:

Well, let's test this assertion.  Suppose a consortium of electric
companies develops a UDP-based protocol  for monitoring and controlling
street lights. It turns  out that  this protocol generates  an unbounded
amount  of traffic (say,  proportional to  the square  of the  number of
street lights  in the world), has no  congestion control, and no
security, but  is expected to run over the Internet.
According to you, this has nothing to  do with the IETF.  It might result
in the congestive collapse of the Internet,  but who cares, the IETF
doesn't do street  lights.  I would  like  to see  the  criteria  which
determine  that telephones belong on the Internet but street lights don't!
thanks for making the most concise statement of the conflict here in the 
discussion so far!
I think this point is one of the critical causes of conflict when talking 
about the IETF mission - and unless we lance the boil, actually talk about 
it, and attempt to *resolve* the issue, we will go on revisiting the issue 
forever, with nothing but wasted energy to show for it.

In the discussions leading up to this document, we actually had 3 different 
other levels of "inclusivity" up for consideration:

- "Everything that runs over the Internet is appropriate for IETF 
standardization". Obviously, that might cause some reactions from 
organizations like the W3C, OMG, ISO, ITU, the power grid standardizers, 
the bank transaction standardizers and others even if the IETF were 
able to gather the required competence, it's hard to see how we could build 
a management structure that could handle "everything".

- "Everything that needs open, documented interoperability and runs over 
the Internet is appropriate for IETF standardization". A bit smaller, but 
still huge, and hard to draw boundaries around. Advantage: Everything we 
currently work on is unquestionably part of the IETF's scope.

- "Everything that builds infrastructures on the Internet that needs to be 
open and interoperable is appropriate for IETF standardization". This would 
place SMTP, DNS and LDAP (in the original vision) inside the IETF's sphere, 
but would leave the traffic lights (and the current way LDAP is used) 
outside it.

- "Everything that can seriously impact the Internet is appropriate for 
IETF standardization". Argues for keeping HTTP and DNS, would include your 
hypothetical traffic lights, but would probably leave POP/IMAP out, and 
leaves people arguing about both SIP and L3VPN.

- "For the Internet" - only the stuff that is directly involved in making 
the Internet work is included in the IETF's scope.

It's far from clear in my mind what the right thing is, or what the 
appropriate path forward is if the IETF regards its purpose as being one or 
the other - we might, for instance, decide that we standardize stuff that 
needs to be open and interoperable, but have different evaluation criteria 
for those things than for those things that "make the Internet work", and 
will dispose our resources accordingly - I don't know. And if we decide 
that certain things we currently do are outside our scope, we've got a 
responsibility to make sure the work effort is handled in a responsible 
fashion.

But it's relatively clear to my mind that continuing to have both sides of 
a discussion argue based on "the mission of the IETF", with conflicting 
definitions, is not the best thing for the Internet.

So - rather than stating something completely vague, we put out a proposal. 
If it's the wrong proposal, it should be changed. But please be specific 
about what you think it should be changed to.

makes sense?

 Harald

Re: IESG proposed statement on the IETF mission

[Scott W Brim]

On Wed, Oct 15, 2003 01:01:53PM -0400, [EMAIL PROTECTED] allegedly wrote:
> 
> Hi Scott,
> 
> > Similarly for almost all of the rest.  What's the point?  Are you
> > reiterating the problem-statement work?  They're doing all right,
> > although perhaps you could help push the work to completion.  It would
> > be much more useful for you to reaffirm the fundamental 
> > principles that are not on the auction block.
> 
> >From your perspective, what are those fundamental principles?

I can't do that today, but will reply soon.

Re: IESG proposed statement on the IETF mission

[Valdis . Kletnieks]

On Wed, 15 Oct 2003 12:48:37 EDT, Keith Moore said:
>
> I certainly don't believe "only" in rough consensus and running code -
> I also believe in explicit definition of goals and requirements,
> careful design by knowledgable experts, analysis, iterative
> specification, wide public review, etc.

Of course, proper design and development techniques increase the likelyhood of
running code - and "proof by example running code" is always a good way to
achieve a consensus. 



pgp0.pgp
Description: PGP signature

Re: IESG proposed statement on the IETF mission

[Keith Moore]

> One  would hope instead that the  IETF would want to
> encourage competition between different  views of Internet evolution, as the
> competition of ideas is the way to make progress. 

what I would say instead is that the IETF should encourage this competition 
within the sphere of architectural discussion - well in advance of development
of specific standards or deployment of specific products.

RE: IESG proposed statement on the IETF mission

[Margaret . Wasserman]

Hi Scott,

> Similarly for almost all of the rest.  What's the point?  Are you
> reiterating the problem-statement work?  They're doing all right,
> although perhaps you could help push the work to completion.  It would
> be much more useful for you to reaffirm the fundamental 
> principles that are not on the auction block.

>From your perspective, what are those fundamental principles?

Margaret

Re: IESG proposed statement on the IETF mission

[Eric Rosen]

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

> 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. 

Well, let's test this assertion.  Suppose a consortium of electric companies
develops a UDP-based protocol  for monitoring and controlling street lights.
It turns  out that  this protocol generates  an unbounded amount  of traffic
(say,  proportional to  the square  of the  number of  street lights  in the
world), has no  congestion control, and no security, but  is expected to run
over the Internet. 

According to you, this has nothing to  do with the IETF.  It might result in
the congestive collapse of the Internet,  but who cares, the IETF doesn't do
street  lights.  I would  like  to see  the  criteria  which determine  that
telephones belong on the Internet but street lights don't!

Another problem  with your  formulation is that  the Internet is  a growing,
changing, entity,  so "for the Internet"  often means "for what  I think the
Internet  should  be  in  a  few  years", and  this  is  then  a  completely
unobjective criterion.  One  would hope instead that the  IETF would want to
encourage competition between different  views of Internet evolution, as the
competition of ideas is the way to make progress. 

I also do not understand whether "for the Internet" means something different
than "for IP networking" or not.  

I think  it should  also be part  of the  mission to produce  standards that
facilitate the migration to IP  of applications and infrastructures that use
legacy networking  technologies.  Such  migration seems to  be good  for the
Internet, but I don't know if it is "for the Internet" or not. 

Re: IESG proposed statement on the IETF mission

[Keith Moore]

overall, I like the document.  some comments:


> However, while Dave Clark's famous saying
> 
>   "We do not believe in kings, presidents, or voting.
>We believe only in rough consensus and running code,"

is this an accurate quote?  I've usually seen it written

We reject kings, presidents, and voting. 
We believe in rough consensus and running code.

I agree with this form, but not with the way you've stated it.
I certainly don't believe "only" in rough consensus and running code -
I also believe in explicit definition of goals and requirements,
careful design by knowledgable experts, analysis, iterative
specification, wide public review, etc.

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

I actually believe IETF has a somewhat wider purpose than that.  What
I usually say is "we're trying to help the Internet work better".
We do this partially by authoring and maintaining protocol standards, 
but we use other mechanisms also.  In addition to standards, we produce 
informational and experimental documents and BCPs.   We provide formal 
and informal advice and feedback to various parties about operational
practices,  implementation practices, efforts by other SDOs, proposed
regulations, etc.  All of these are relevant to, and consistent with,
the purpose of helping the Internet to work better.

We *ought* to provide more architectural direction or advice - our
failure to resolve architectural issues in advance of deployment of
products with conflicting views of the architecture (or in some 
cases, a simple lack of care or foresight on those vendors' parts) has
caused a number of conflicts and operational problems, and has impaired
the ability of the Internet to support diverse applications.

I also believe that some amount of experimentation (perhaps not all
that is being done under IETF's purview) is part of the process of
"trying to make the Internet work better"

> The IETF
> has identified interoperability, security, and scalability as
> essential, but without attaching measurements to those
> characteristics.

that's a start.  there are a lot more characteristics than these that
should be considered in a design, that we haven't articulated yet,
but we need to.

> 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.

I disagree with the sentiment as I understand it.  I don't think it's
realistic anymore to take the view that what people run entirely on 
private networks is their own business and outside of IETF's purview. 
NATs, private addresses, and DHCP with short lease times have all had
devistating effects on the Internet's ability to support applications. 
Insecure applications can facilitate the breeding of viruses that affect
the entire network even if their intended interactions are only between
a local client and server.

We do have to limit our scope.  We don't have the ability to scale to
the point where we could standardize everything that uses IP, and it
would be silly of us to try to claim authority to do so.  But it might
be reasonable for us to define standards for how local networks work
(to provide applications with a predictable environment), or to define
standards which all applications should adhere to (to minimize security
issues) which can be incorporated by reference into other protocol
specifications.

regarding the section on "Quality and Architectural Review".  what strikes
me about this section is the (implicit) assumption that architecture is
done after the fact.  rather than looking ahead to minimize and resolve
conflicts well before they acquire the inertia of wide deployment, we 
try to fix things after the fact.

Re: IESG proposed statement on the IETF mission

[Scott W Brim]

On Tue, Oct 14, 2003 11:48:10PM +0200, Harald Tveit Alvestrand allegedly wrote:
> As part of the discussions about change process within
> the IETF, the IESG has come to believe that a somewhat longer statement of 
> the IETF's mission and social dynamics might provide useful context for the 
> community's discussion.  As part of that, we'd like to put the following 
> document out for feedback.
> 
> It incorporates lots of ideas and some text from existing RFCs
> and IETF web pages, but is more focused on change than those have
> been.  We hope it captures a sense of the context of the work of
> improving the IETF, by capturing some of the social dynamics which
> have been an implicit part of the IETF's work and style over the years.

OK, but first, it doesn't clarify the mission, or the social contract.
At most it makes a couple vague statements after describing some general
problems.  It looks like the IESG has some sense of where the
problem-statement/solutions process is going, and wants to run with it.
That's okay -- but please say explicitly that's what's happening, if it
is.

> We also hope that by making some of those implicit elements more
> explicit, we may find it easier to understand how to make changes
> that will "go with the grain" of the IETF's history and culture.

What I want is a renewed, clear statement of the fundamental principles
of the IETF which must not be violated or weakened during the
problem/solution process.  It's important that the leadership of the
IETF keep clear themselves on what the fundamental principles are, and
to reiterate them when necessary (like now).  That's part of the social
contract itself.  There are principles which are at the heart of the
organization and which the (pseudo-)consensus process doesn't get to
touch.

> The IETF Mission
> 
> 
> The IETF's mission has historically been embedded in a shared
> understanding that making engineering choices based on the long
> term interest of the Internet as a whole produces better long-term
> results for each participant than making choices based on short term
> considerations, because the value of those advantages is ultimately
> derived from the health of the whole.  The long term interest of the
> Internet includes the premise that "the Internet is for everyone".
> 
> Two years ago, the IESG felt that making the mission of the IETF
> more explicit was needed.  The following terse statement has since
> been promulgated, first by IESG members and then by others:
> 
>"The purpose of the IETF is to create high quality, relevant,
> and timely standards for the Internet."

The purpose of the IETF has always been to make the Internet work
better, in measurable operational terms.  All else descends from that.
We do standards because we have to, for now and for the future.  Why do
we care about network operators being in the room if our prime mission
is to make standards?  Why do we care if there are two interoperable
implementations?  The operations work of the IETF is important unless it
is being taken care of elsewhere.  It isn't frosting on a standards body
cake, it's just as important as standards.  

Beyond that, yes, the IETF is primarily an SDO, because many operational
issues and agreement on deployment BCPs are being taken care of by other
means, and also because standards is our main measurable output in the
eyes of the outside world.  The above statement applies, but it is not a
basic principle.  It derives from our fundamental responsibility, to
have an Internet that works well today and is robust and flexible enough
to work well in the future.

> 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.

A very poor distinction.  Everything runs on the Internet eventually,
regardless of what private area it was meant for to start with.
Experience is that everyone wins if there are Internet-compatible ways
of doing things from the beginning.  I fully expect street light control
to run as a secure service along with many other services over a generic
IP network.  However, it's okay to say that priority will be given to
work on the public Internet.

> 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
> gro

Re: IESG proposed statement on the IETF mission

[Melinda Shore]

It's an interesting document, but it looks to me a bit much
like a problem description and I'm not sure how it relates
to other existing work (the problem description document in
the problem working group, most obviously).  I particularly
liked the discussion of the IETF mission - it could provide
the basis for tackling one problem that's been raised on
a number of occasions, which is that the organization doesn't
have a clear sense of mission or vision.  Even though in the
first paragraph of the "Social Dynamics" section you say that
"As they are neither good nor bad, it is not appropriate to
call them "problems;" rather think of them as social forces
and dynamics" a number of them really are framed as problems.
Indeed, it would be hard to define some way in which statements like
"making integration more difficult" are not problem statements.
I'd really like to see the document, which I think has good
fundamentals, refocused on mission and goals.
Melinda

IESG proposed statement on the IETF mission

[Harald Tveit Alvestrand]

Greetings,

As part of the discussions about change process within
the IETF, the IESG has come to believe that a somewhat longer statement of 
the IETF's mission and social dynamics might provide useful context for the 
community's discussion.  As part of that, we'd like to put the following 
document out for feedback.

It incorporates lots of ideas and some text from existing RFCs
and IETF web pages, but is more focused on change than those have
been.  We hope it captures a sense of the context of the work of
improving the IETF, by capturing some of the social dynamics which
have been an implicit part of the IETF's work and style over the years.
We also hope that by making some of those implicit elements more
explicit, we may find it easier to understand how to make changes
that will "go with the grain" of the IETF's history and culture.
We'd be happy to have feedback on it, either sent to the IETF list
for public discussion or to the IESG.  This is an informal piece of work, 
and may never be published in RFC form, but may rather appear on the IETF 
web pages somewhere.

Your comments are welcome!

Harald Alvestrand
        For the IESG

The IETF Mission and Social Contract


Introduction


The Internet Engineering Task Force (IETF) is a large open
international community of network engineers concerned with the
evolution of the Internet architecture and facilitating the
operation of the Internet.  In the seventeen years since thirty-odd
engineers first met in a single room, the Internet and the IETF
have grown considerably; the IETF is attempting to adapt to these
changes.

Most of the basic processes and the social contracts by which the
IETF works, both formal and informal, were developed when it was a
community of fifty to two hundred engineers.  Much of its internal
communication depended on long-term personal relationships and an
implicit understanding of shared goals and culture.  This has
worked well for many years and much growth.  The IETF has been and
is a very successful organization, and has produced much serious
work which has both furthered its own goals of Internet evolution
and had a notable effect on global human society.

The processes and social contracts that worked for fifty engineers
have managed to sustain the IETF in dealing with a community of
thousands of engineers and a greatly expanded technology and market
space.  However, while Dave Clark's famous saying

  "We do not believe in kings, presidents, or voting.
   We believe only in rough consensus and running code,"

is still a touchstone of the IETF culture, the rapid growth of
participation in the IETF, the growth of the Internet itself,
and the rapid integration of Internet technology in  real-world markets
and society in general are seriously straining the IETF's traditional 
understated and informal communication and methods.

Though the process of organizational change has actually been going
on continuously for a long time, it would be useful to state more
formally many previously implicit understandings and to make
explicit some previously informal processes.  This note tries to
lay the social foundation for that continuing journey.


The IETF Mission


The IETF's mission has historically been embedded in a shared
understanding that making engineering choices based on the long
term interest of the Internet as a whole produces better long-term
results for each participant than making choices based on short term
considerations, because the value of those advantages is ultimately
derived from the health of the whole.  The long term interest of the
Internet includes the premise that "the Internet is for everyone".

Two years ago, the IESG felt that making the mission of the IETF
more explicit was needed.  The following terse statement has since
been promulgated, first by IESG members and then by others:

   "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.  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.

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.

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 d