Subject: RE: The need for smaller protocol specifications

From: "Bound, Jim" <[email-masked]>
Date: Mon, 9 Jun 2003 16:33:48 -0400

I agree with Charlie but not hearing anyone comment?

Maybe I am paranoid but here is what I hear happening:

1.  Bob Hinden suggested an idea for time to market.  Not one IESG
person said this is a good idea not as IESG person but folks who have
IESG experience.

2.  Charlie gives below I think accurate description at a minimum a
problem we face. Again no IESG response here.

It could be we are still in define problem space so discussion solution
is not time.  Or anything we propose that fixes anything other than an
intergalitic high level process will not be discussed and esp by the
IESG members not as IESG members but as persons in that role with
experience.

Chairs I have to ask where are you at with the above two bullets if
adopted they clearly require a change and action by the IESG.  It feels
to me the IESG and even past IESG persons don't want to do anything that
causes that?  Thats my read of all these threads.
We are experiencing the same problems on this mail list we are
discussing.
What are your thoughts?  If we are just going to flirt with fixing
problems again I see not point in continuing.  This is exactly what the
ADs do too. A member makes a very logical base statement as the two
above and then we get silence from ADs.  Why?  IMO because it shows a
problem in their ranks and they won't admit it.  But all here are more
than willing to blast WGs, Chairs, and Authors.  This list is proving
there is a problem real time.  It is happening before your eyes.
Another IESG member blasted vendors twice this weekend.  I asked them
will you stop this?  No answer and none privately.  If I was not a nice
guy I would send that mail directly to Sr. VPs I know in those companies
and say here is what IESG member said about you on a public mail list.
But I am trying to be a nice guy.  The key problem with IESG is they
think they are beyond the rules and basic codes of engineering
discussion and responding to questions.  Or they don't answer the
question as engineers but as politicians with quip mores and folkways
that are not answers to the questions.  How do we document this problem?
I simply do not know.

thanks
/jim

> -----Original Message-----
> From: Charlie Perkins [mailto:[email-masked]] 
> Sent: Monday, June 09, 2003 3:28 PM
> To: Harald Tveit Alvestrand
> Cc: [email-masked]
> Subject: Re: The need for smaller protocol specifications
> 
> 
> 
> Hello Harald,
> 
> I agree with your statements, and I wonder if you see the 
> value of my argument.
> 
> Do you think that protocol specifications today are (generally
> speaking) too complicated, about right, or not yet complicated enough?
> 
> Regarding "good for AT LEAST ONE THING", does it
> mean there has to be a killer app?  What about IPv6--?
> 
> Regards,
> Charlie P.
> 
> 
> 
> Harald Tveit Alvestrand wrote:
> 
> > Charlie,
> >
> > clipping mercilessly from your message....
> >
> > --On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins
> > <[email-masked]> wrote:
> >
> >> Another way to say this, is that we are being required to specify 
> >> entire systems instead of protocol components.  I think this is a 
> >> very bad idea.  I think the IESG should sincerely reconsider this 
> >> policy, and let protocol specifications be published EVEN 
> IF they do 
> >> not solve the entire problem domain, but just a part of it. 
> >> Typically, the part that the original protocol specification DOES 
> >> solve, will be implemented and tested for interoperability.  The 
> >> other stuff that gets glued on will just sit there like a dark 
> >> jungle.
> >
> >
> > The way I thought of it in the apps area 5+ years back was that a
> > proposal has to document that it is good for AT LEAST ONE THING. (I 
> > failed that at times - for instance with TIP, which I still 
> don't know 
> > if anyone uses).
> >
> > We (the IETF) want to standardize useful protocols. If 
> there isn't at
> > least one scenario where the protocol is clearly useful, I see 
> > absolutely no reason to standardize it. So describing the scenario, 
> > including all the bits and pieces from other protocols that 
> have to be 
> > there in order to make the protocol useful in that 
> scenario, is, to my 
> > mind, a necessary part of documenting the protocol.
> >
> > On the other hand - if a scenario is described, and it's 
> obvious that
> > 5 mins after the protocol-implementing product hits the street, it 
> > will be used in another scenario, where the proposed 
> "supporting bits" 
> > are clearly going to lead to undesirable situations (I'm thinking 
> > about SNMPv1 and the "community string" here, for 
> instance), then we 
> > as a community have a responsibility to describe those 
> scenarios too, 
> > and provide/reference the adequate mechanisms for those 
> scenarios. For 
> > instance by saying that all IPv6 implementations MUST have IPSec 
> > support (the "Danvers Doctrine"), or saying that applications MUST 
> > behave in the face of congestion (RFC 2914).
> >
> >                 Harald
> >
> >
> >
> >
> >
> 
> 
>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 09 Jun 2003 14:23:30 -0700

Hello Jim,

I tried to make this short.

My belief is that the IESG demands full-blown system specifications
because anything less "could" be implemented inside systems that
have features they don't like.  Some would say that such demands
are characteristic of "control freaks".  I won't go that far, but it's
certainly an interesting point.

A good example is key distribution. If a protocol requires authentication,
but does not specify a key distribution mechanism, then the security AD
can ask "How can I use this without key distribution?".  The answer could
be by manual configuration, proprietary protocols, IKE, something new
under development in 3GPP$%*, or whatever.  But, by imposing the
(undocumented anywhere!) requirement for a key distribution adjunct,
the IESG
1) delays the specification
2) puts the design responsibility in a perhaps unprepared working
     group
3) discourages future development of appropriate key distribution,
4) causes protocol bloat, and
5) has a harder time judging the resulting document.
It is my belief that the IESG has to bite the bullet and stop causing
those effects.  The cure is worse than the disease they tried to heal.

Separate protocol specifications are better, and more workable if
allowed to progress towards deployment and market acceptance
at different rates.  Perhaps early system implementations won't do
the absolutely shiniest best thing, but anyway they will provide good
experience for later implementations.

We have _got_ to stop thinking that everything has to be perfect
before it is useful.  It's not like a space shuttle where we only
get one chance.  And even the best engineering has mistakes.
That's life!  The IESG can never change that.

Very similar complaints could be lodged against requiring
discovery protocols to be part of base specifications.
In the cases I am most familiar with, this was not an imposition
from the IESG, but a response to a feared response from the
IESG.  In fact, as the number of potential protocol interactions
grows nonlinearly in the Internet, we can no longer demand that
every protocol must have its interactions with other protocols
documented and specified completely -- at least for Proposed
Standard!!  We have to have a process more friendly towards
incremental refinement.

And, finally, to reiterate for emphasis in hopes that no one
would forget, this is not a black and white thing.  It's a matter
of balance, and lately the results have become terribly unbalanced
towards unmanageable protocol complexity.

Regards,
Charlie P.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 09 Jun 2003 17:45:45 -0400

> adopted they clearly require a change and action by the IESG. 

The charter is very specific in excluding defining solutions
from the scope of our work.  To the extent that solutions
have been discussed here it's been 1) to help frame our
understanding of the problems, and 2) to try to figure out
what to do about "short-term" problems that can be fixed
without the overhead involved with starting up a new working
group.  The latter certainly excludes any kind of IESG
restructuring.

Allow me to point out that the more focused we remain on our
two documents the more quickly we can get them wrapped up
and move on to whatever solutions phase/process/what-have-
you we've identified.

Melinda

---

From: Randy Bush <[email-masked]>
Date: Tue, 10 Jun 2003 17:37:39 +0900

> person said this is a good idea not as IESG person but folks who have

'timely' was one of the ajdectives in the terse iesg statement of the
ietf's mission.

> problem we face. Again no IESG response here.

a formal iesg response would take two years as it would have to pass
iab and isoc review :-)

and, by now you will have seen a number of responses.  folk are just
busy.  e.g., i was on a plane over the pacific.  patience, guy.

i think harald said it well, and i will paraphrase.  yes, protocols
often get far too complex.  but the way charlie phrases the issue
could much more easily be used for things i would not support than
for things i would.

randy

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 10 Jun 2003 07:15:54 -0700

Hello Randy and Harald,

If my characterization of the problem was too general,
perhaps you can help to refine it.  If you have examples
showing how my characterization could be used the
wrong way, please help by discussing your examples.

If you think that my example of key distribution seemed
like a perfectly legitimate exercise of IESG power, then
I don't think we're likely to come to agreement, and I would
view your opinion as leaning towards requiring specification
for entire systems as opposed to mere protocols.

Do you prefer system specifications or protocol specifications?

Here would be one possible formulation for what I see as
a major problem (perhaps _the_ major problem!):

-- The IESG has tended to require protocol specifications that
    specify entire systems, instead of simple component protocols.
    This limits the applicability of the component protocols to
    work only in the particular larger system, complicates the
    implementation of the component protocols, and delays the
    publication of the component protocols.

Regards,
Charlie P.

PS. I do not believe that IP would pass IESG review today.
      Think of all the attacks based on routability!

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Jun 2003 10:28:18 -0400

--On Tuesday, 10 June, 2003 07:15 -0700 Charlie Perkins 
<[email-masked]> wrote:

>...
>     specify entire systems, instead of simple component
> protocols.     This limits the applicability of the component
> protocols to     work only in the particular larger system,
> complicates the     implementation of the component protocols,
> and delays the     publication of the component protocols.

Charlie,

While I would often agree with the above, I think there is 
another, balancing, problem.  Perhaps there are differences by 
area or topic, but I think it would be equally accurate to say:

	-- The IESG has tended to approve simple component
	protocol specifications without an adequate
	understanding of the systems and contexts in which those
	protocols will be used.  If vendors or users adopt the
	protocols without adequate consideration of those system
	and contexts, this may create considerable risks for the
	overall operation of the Internet.  While protocol
	specifications should not be expected about every
	possible application and context, they should include
	documentation that describes which contexts have been
	thought out and evaluated and which ones, if any, are
	known to be inappropriate.

There is obviously a balance that should be found and kept here. 
Slogans like "complete systems only" and "small components only" 
are unlikely to lead us to progress, quality, or understanding. 
Note that I don't think you have been invoking such slogans 
--I've found your notes helpful and thoughtful-- but it is only 
a small step from what you have said, or my response above, to 
them.

regards,
    john

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 10 Jun 2003 10:50:29 -0700

Hello John,

I think your reformulation will help to refine the problem.
Comments below.

John C Klensin wrote:

>        ..........               I think there is

Exactly.  This is an engineering problem, not a mathematical
problem, and I have tried to emphasize the need for balance.

Your suggested solution (eek!  solution space!) seems workable
to me, but notably it does NOT imply that the partcular contexts
are codified as necessary parts of the base specification.
Indeed, once again we may be asked to upgrade the "applicability"
part of the specfication.  This should be understood as
a _possible_ application of the protocol, and not the _only_
application of the protocol.

> are unlikely to lead us to progress, quality, or understanding.

One person's "slogan" is another person's "engineering guideline".
I do not believe that understanding good engineering guidelines
is a hindrance.  Perhaps you meant to suggest that no such guidelines
are immutable, but have to reflect current practice and understanding.

I am suggesting that the current trend towards demanding complete
system specifications is itself a mighty hindrance.

> a small step from what you have said, or my response above, to

Thank you very much for the encouragement, and I hope we can
continue to refine this particular problem statement.

Regards,
Charlie P.

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Jun 2003 03:31:03 +0900

> -- The IESG has tended to approve ...

note that this kind of phrasing is part of the polarization game.
the wgs also approve or not.  there is ietf last call where all
sorts of "but it does not interoperate with X, has a horrible
security hole Y, ..." are, or used to be and probably should be,
raised.

randy

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jun 2003 13:42:09 -0700

Randy,

>> -- The IESG has tended to approve ...

RB> note that this kind of phrasing is part of the polarization game.

actually, challenging it in this way has more to do with polarization
than does the original statement.

how is it possible to sustain constructive discussion about perceptions
and problems if people are not able to state their perceptions in a
simple and direct fashion?

There is nothing rude or even challenging in the tone of the original
language. Whether it is correct is independent of whether it is
reasonable to make such a statement.

If anyone offering their understanding of the situation, who
happens to include in that statement some assertion about the iesg, is
going to be treated to such a challenge -- particular from an AD -- then
we are faced with what can only be classed as a hostile work
environment.

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Jun 2003 17:40:00 -0400

--On Tuesday, 10 June, 2003 10:50 -0700 "Charles E. Perkins" 
<[email-masked]> wrote:

>>         understanding of the systems and contexts in which
>>         those protocols will be used.  If vendors or users
>>         adopt the protocols without adequate consideration of
>>...
> Your suggested solution (eek!  solution space!)

Sorry.  Too much experience/context in optimization-related 
techniques, which were, in my experience, engineering tools and 
disciplines (see below).

> seems workable
> to me, but notably it does NOT imply that the partcular
> contexts are codified as necessary parts of the base
> specification. Indeed, once again we may be asked to upgrade
> the "applicability" part of the specfication.  This should be
> understood as a _possible_ application of the protocol, and
> not the _only_ application of the protocol.

Absolutely.   But that formulation, which I think is the correct 
one, suggests that we ought to be prepared to update statements 
about applicability (or lack thereof) as often, or more often, 
than we update the protocols themselves.

>> Slogans like "complete systems only" and "small components
>> only" are unlikely to lead us to progress, quality, or
>> understanding.
>
> One person's "slogan" is another person's "engineering
> guideline". I do not believe that understanding good
> engineering guidelines is a hindrance.  Perhaps you meant to
> suggest that no such guidelines are immutable, but have to
> reflect current practice and understanding.

I can accept that definition.

Part of the tension I'm feeling is that I heard what was, for 
me, a wonderful definition of "the engineering discipline" many 
years ago, and it featured "tinkering" as the key element. 
"Tinkering"-based definitions are entirely consistent with 
"smaller pieces" models and incremental development of many 
sorts.  The author believed that, if a problem had a single 
possible solution that could be derived uniquely from 
well-established (or provable) principles, it might be "science" 
or "mathematics", but it wasn't engineering.   Engineering 
problems, in that view, were characterized by collections of 
goals and constraints and the processed used to find a solution 
that was a reasonable match to them (with "economics" and "how 
long do we really have to do this, and how much does more time 
'cost'?" typically being part of the constraint set).

The difficulty is that, while many of those same issues apply to 
standardization processes, they are intrinsically a bit 
different.  In some ways, standardization is about determining a 
constraint set --or part of it-- against which engineering can 
occur.  If that wasn't the case, we wouldn't need to worry as 
much about interoperable implementations, because only one 
narrowly-defined class of implementation solutions would be 
possible for a given standard.  So, in writing a standard, we 
need to determine how to define an acceptable solution, at least 
partially in terms of the constraints on it.    That is a bit 
different from "engineering problem" and even more different 
from "engineering solution".  And I think we need to keep the 
differences and similarities clear, lest we accidentally go too 
far in one direction or the other and find ourselves hamstrung.

> I am suggesting that the current trend towards demanding
> complete system specifications is itself a mighty hindrance.

And we agree about that as well.

    regards,
      john

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 11 Jun 2003 07:31:36 +0200

The overall problem I think is that in general people in the IETF don't 
spend enough time reviewing documents and architectures. One small 
group of people which soooo much want something done, something which 
makes sense from their perspective write a draft, and "push it through 
the system". The only real pushing today which is needed is the 
creation of a working group.

When the working group is created, the pushing is within the working 
group. Either we have an active wg chair which ensure review and proper 
document OR the small group keep pushing.

When the wg is "ready" with the document (either the document is really 
ready, or the small group has pushed enough to make the wg chair tired) 
the document end up with IESG.

What are the different paths to here? (from my perspective after being 
5 years AD, 1998-2003):

(1) The document is really good, as it should.

(2) The small group of active people is still active. The wg chair was 
tired and no one in the wg except the small group has reviewed the 
document. The document in reality because of this comes to the IESG 
from the small group without any other review.

(3) The small group ended up being so tired after pushing for the wg 
and pushing the wg chair that they faded away. The wg chair (maybe not 
even the same as from the beginning of the wg) has more with whip than 
carrot managed to get some other doc editor to finally produce the 
document. The document is quite good quality, but, the original idea is 
lost, and possibly the final document is not the bright idea as 
originally (and it is normally _very_ late).

(4) The document never reach the IESG at all.

During my years, I saw fewer and fewer documents in the (1) category. 
The only category where IESG can "rubberstamp" an I-D. As area director 
I didn't want anything else than just rubberstamp something.

More and more drafts ended up in category (3). A few in (2). As (2) and 
(3) has to be treated so differently, it is hard as AD to find a good 
mechanism for how to work efficiently. Also, an increase of documents 
in the (2) and (3) category increases the workload of the AD.

I feel Charlie talks about more category (2) documents be classified by 
the AD as (1). This means the AD should "trust" the wg doing a good 
job. This is exactly what the AD want as well, BUT, part from being the 
last line of defence against crap, the AD is also the one which decides 
whether proper review has actually happened.

Personally, I looked for a few things to make the decision whether a 
document was (1) or (2). Simple things which is in the I-D Nits list. 
They include:

  - Do grep for the following strings "UTF-8", "Unicode", "Character", 
"ASII".
    If any of these are included, are they described correctly?
  - Check if normal domain names are used, or "example.com" style.
  etc...

If the document fail on any of the above, the document is clearly a 
category (2) document. However I wanted it to be a category (1).

Category (3) is the hardest though. A document finally arrives at the 
IESG. If the AD find some bugs, a message is sent back to the wg chair 
(and in some cases the wg). Nothing. A few weeks later, one might 
remember to ping the wg which in reality is in what I would call zombie 
state. Finally something comes back, and then the AD doesn't remember 
what happened, and the mental/thinking-process needs to restart. VERY 
expensive.

When reading this list, I find _all_ people seems to think we should 
have more documents move from category (2) -> (1), and possibly more 
(3) -> (4).

That will definitely decrease the workload of the AD, we get rid of 
boring crap (which possibly will not be used on the Internet anyway). 
The wg will get more power as the number of category (1) documents 
increase.

BUT, it will be hard to get there.

The reason why I as AD felt more documents ended up in (2) or (3) 
include:

  - I found more and more documents with bugs which could have been
    fixed by doc editor just by reading I-D Nits (see above)
  - I almost _never_ got any reaction what so ever (positive or negative)
    on IETF Last Call

In this situation, and being the last line of defence, I feel I have to 
do a more detailed review. I feel I can not, however I would like to, 
trust the wg.

At the same time, this leads to the AD being questioned doing 
micro-management, requiring too much from the document, etc etc which I 
see between the lines in what many have said.

And, I really understand this complaint. I really do. Really really 
really!

I feel the meta-question is how to start turning the wheel the other 
way around. How do we make sure the wg produce documents which can be 
rubberstamped by the AD, documents which are not crap? How do we make 
wg's produce better documents? How do we make sure Last Call is 
happening?

I state it this way because I don't think the problem is what level of 
quality IETF in the current process require. I think the problem is 
really that we don't know where it is evaluated whether the document 
has reached this level. Whatever the level is.

Many many people agree it is better if this review happen early in the 
process. How? How do we know it has happened? I know the only way to 
convince an AD that it has happened is to give documents to IESG which 
does NOT fail any of the things in the I-D nits document. Claiming it 
has got review, and then failing I-D nits is not good. At the same 
time, having an AD late in the process require changes is not good 
either? It polarises things. It ends up  being a "we" and "them". Not 
good.

We have the timeline in the wg charters. Maybe what we need is an 
objective way of forcing documents through the process. We create real 
steps the doc have to go through, and each step has a deadline. If the 
deadline is not met -- start from the beginning again. The deadlines 
are set by the wg like today. That way we at least remove all category 
(3) documents from the IESG load, but we might also be able to "force" 
the wg to do more proper review? It might be easier for both a wg chair 
and AD to "just say no" and then spend time on things which need real 
help, like synchronisation across areas _during_ the creation of a 
document and not after.

I don't know.

But, I definitely think we need to talk more carefully about where the 
review is done, and how we make sure it is done. As AD, I found it very 
very hard in problematic wg's to both review process and document 
quality. Very often these two roles are fighting each other.

     paf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jun 2003 10:12:01 +0200

>>>>> =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes:

[...]

Thanks for your note - I appreciate it.

Patrik> But, I definitely think we need to talk more carefully about
Patrik> where the review is done, and how we make sure it is done. 

Serious document reviews take time (a) for the review itself plus (b)
for the followup discussions (and in my experience b >> a). The only
reward for such a time investment is (perhaps) being mentioned in the
acknowledgements section.

To achieve more and better reviews, we simply have to make it more
attractive for people to spend their time on serious reviews.

[I am repeating this statement here, which I have made in the past,
 because I feel that the importance of this is still overlooked.]

/js

-- 
Juergen Schoenwaelder		International University Bremen
Phone: +49 421 200 3587		P.O. Box 750 561, 28725 Bremen, Germany
Fax:   +49 421 200 3103		<http://www.iu-bremen.de/>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Jun 2003 12:23:53 +0300 (EEST)

> Thanks for your note - I appreciate it.

Also totally agree; very well written note, and one I agree with :-).

> attractive for people to spend their time on serious reviews.

I agree.  My experience is that even if you very detailed reviews, people
don't always acknowledge you.  Many don't even have the acknowledgements
sections in the drafts.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jun 2003 11:27:57 +0200

And see http://graybeards.net/sirs/ for the prototype solutions effort.

  Brian

---

From: Scott W Brim <[email-masked]>
Date: Wed, 11 Jun 2003 10:24:19 -0400

> creation of a working group.

\${leadsto} ... SIRS

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 11 Jun 2003 10:41:58 -0400

Hi Scott,

> > creation of a working group.

How so?

Do you have some reason to believe that there are small groups of
people that can effectively push something through the IETF that
don't include a few SIRs?

If a few positive SIR reviews lead to lower scrutiny by the IESG,
then SIRs might actually make it easier for a small group of
people to push something through.  Note that I don't necessarily
consider this to be a bad thing...

Margaret

---

From: Scott W Brim <[email-masked]>
Date: Wed, 11 Jun 2003 11:00:21 -0400

> consider this to be a bad thing...

[swb inches his way around the solutions lagoon ...]

I tend to trust the IESG, and I have yet to see an incarnation of it
which I would call stupid.  If the SIRS reviewers are selected from a
narrow pool, perhaps all participants in the WG in the first place, that
might lead to even more scrutiny.  In any case it wouldn't be less.

I agree with the problem as originally stated, that many documents don't
get enough review, especially with what they expect from other
technologies.

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Jun 2003 16:39:16 -0400

> have features they don't like.

I don't think this is true in general.  To the extent that it is true, 
I suspect it has something to do with the expectations that the IESG 
(and perhaps the public) have for that particular technology.

I'll give an example not involving IESG.  Once I had lunch with the 
person who was then the head networking official for the University of 
Tennessee.  He complained to me about the limitations of Mobile IP.  I 
replied that Mobile IP was just fine as long as you understood its 
limitations and didn't expect it to solve every version of the "I want 
my host to be able to be mobile and still talk to the network" problem. 
  (note, this conversation was a few years ago, so it's not a statement 
about the state of mobile IP today).

But the natural expectation of something called "mobile IP" is that it 
_will_ solve your version of the mobile IP access problem (which given 
the number of different versions of that problem, essentially means 
that mobile IP is expected to solve all versions of that problem).

Now actually I think it's perfectly reasonable if IESG declares that 
something that calls itself "mobile IP" needs to solve a fairly general 
version of the "mobile IP network access" problem, including security 
etc.  But sometimes the right action might be to change the name or 
otherwise make it clear that this isn't a general solution, and approve 
it for use in the more narrow set of circumstances in which it works 
well - especially if deployment of the 'limited' solution would not 
preclude a later migration to a more general solution.

Other technologies that might be implicitly over-stating their 
applicability include IPsec, DHCP, zeroconf / linklocal addressing for 
IPv4.

(and we're used to thinking that marketing isn't important...)

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 11 Jun 2003 14:05:27 -0700

Hello Keith

> (and perhaps the public) have for that particular technology.

Your story, while interesting, is far afield from my point.
I mentioned several areas which I believe the IESG has
mistakenly required for inclusion in base protocols, among
them key distribution when authentication is a part of
the protocol.

If the IESG wants assurances for a particular technology,
then those assurances should be in the charter statement.
They should not be articulated for the first time during
Last Call.

Regards,
Charlie P.

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Jun 2003 17:12:36 -0400

> They should not be articulated for the first time during

I suspect we'd agree that having WGs carefully define the scope of the 
problem they are trying to solve, and the applicability of their 
solutions, would help a lot.  IMHO, this should start with the charter 
and continue through a WG "problem statement" phase (what we often call 
"requirements" today) and eventually result in an applicability 
statement that is part of the standard.

Now if we could just stop WGs from claiming vastly more applicability 
than their protocols deserve...

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Jun 2003 10:42:56 +0300

Charlie et al, thanks for raising this issue. I believe
large specifications are a significant problem in the IETF
currently, and good points have been made in the discussion.

I'd like to add a few thoughts about the reasons why
we are ending up with large specifications. The discussion
has mainly concentrated on the IESG's requirements, but
in my opinion there are significant other causes for this.
In fact, I wouldn't blame the IESG for this at all...

[Let me add that I have been personally involved in the
creation of several too large specifications, so I know
what I'm talking about ;-) ]

o  We (as in all of us) tend to be too optimistic about
    the complexity of our projects at the beginning.
    We are not very good in estimating how big a specification
    will eventually need to be when it handles all error
    cases, security, etc. Still, document structure stays
    generally fixed from the -00 document. So if the problem
    looked like an easy idea for a 10 page -00 I-D, you
    might have wanted to split the document and protocols
    into subfunctions if you knew it was going to be 100
    pages at the end.

o  Perceived need for speed at the beginning. Can't
    split the document because it would slow us down
    and require multiple WG LCs etc.

o  Working groups generally try to appear as attractive
    as possible towards potential customers of their
    specifications and other stakeholders. For instance,
    there's a need to show that the WG in the first place
    is needed because all these wonderful functions need
    to get done. Or an existing WG wants to ensure that
    it doesn't "lose" against a competing approach.

o  Similarly, if a "beauty contest" is run between two
    approaches in the WG, both approaches end up having
    a lot of features.

o  Requirement processes that we nowadays tend to run
    don't deal well with the prioritization of features.
    If someone can invent a requirement, it generally
    gets fulfilled in the solutions. We don't think
    about cost-benefit analysis enough.

o  Our quality control functions ensure that specifications
    are complete (with all error, multi-version support,
    different network scenarios, security, scalability
    functions).

So, it looks very much like all of us are trying to do
a perfect job. Trouble is, if you multiply all requirements,
all network scenarios, and completeness you get a large
spec.

So what should we do about it? I think the right thing
is to take a serious look at fulfilling all requirements,
and to use modular specification approaches, and roadmaps /
architecture to show interested parties that you will
eventually support all components. And for whatever we
do produce in the smaller specifications, I think its
fine to require it to be complete in the sense of
not breaking the Internet, handling all error situations,
having security (even key management - its often very
application specific), and so on.

--Jari

---

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

> don't always acknowledge you.  Many don't even have the acknowledgements

Speaking for myself:

(a) I don't care one way or another whether I end up in the
acknowledgments section.  If, when I do a review, I am able to help
provide the polish that makes a specification with the potential to
be really good actually achive that potential, then I have more than
enough reward.  What I don't want is to work (as a reviewer or in
any other capacity) on stuff that has no chance whatsoever to be
good.

(b) I've found that when I get the reward I want -- i.e. of being
able to contribute to a quality piece of work -- people are eager to
acknowledge my review efforts in the Acknowlegments section.

What would make it more sttractive to me to do reviews is greater
assurance that at then end of the day a quality spec will result
from the work.  That seems to happen when (and only when) the raw
material that goes in is basically good to start with.

YMMV, of course.

//cmh