Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?)

From: <[email-masked]>
Date: Mon, 9 Jun 2003 09:11:51 +0300

Hi all,

Cutting out the parts of the discussion not relevant to my view:

> if we come to agreement that producing quality and scaling are two
> core problems, then i think there is some organizational and
> management experience from within the computer industry and outside
> from which we can draw some ideas on quality management etc.  but i
> don't think we've reached consensus that these are the issues yet.

If it matters, I believe two major core problems are 

	1) producing quality documents 
	2) solving current scaling problems

and to add a third:

	3) producing timely documents (this has relations to 1 & 2).

Anyhow, perhaps a reasonable way forward would be to see if we
can gain consensus on at least 2 or 3 (not limited to the one's 
I've listed) core problems & start to move forward on them;
while still examining other problems.

John

---

From: Randy Bush <[email-masked]>
Date: Sun, 8 Jun 2003 23:19:18 -0700

i am still unsure, but think basically agree.  so let me pick nits
before getting some sleep.

> 1) producing quality documents

s/documents/standards for the internet/

as i am not sure all we produce is the documents, and i think
we need to keep our focus on the internet.

note that the iesg mission statement from london also included
'relevant,' another easy to measure criterion :-).

> 2) solving current scaling problems

how about 'the scaling problems we understand today,' or something
like that, as we would like what we do to last a while?

> 3) producing timely documents (this has relations to 1 & 2).

yup.  but, as hta points out, there are subtilties here.

randy

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 09 Jun 2003 11:20:52 -0700

Hello folks,

I'm going to try to describe what I see as a major problem, but
the solution is not a black-and-white cure-all rule.  It's more a
matter of perspective, balance, and judgement.

Put simply, protocol specifications are being required to
contain too many features.  In my favorite example, a very
simple signaling protocol specification was eventually required
to also incorporate other related specifications:
- A discovery algorithm
- A key distribution algorithm
- Renumbering algorithms
- Compatibility recipes for an incompatible security protocol
- other stuff too.

The requirement for the key distribution algorithm delayed
the specification for almost three years.

In addition to the obvious problem, there is a more subtle effect
that causes more and more delay.  That is, that as more stuff
gets into the specification, people become less confident about
what is there, and more likely to strip out actually useful features
in a misguided attempt to make the document smaller and more
timely.   All along, the problem is that we are not being allowed to
make small specifications because we have to do all the stuff that
other protocol specifications had to do before the IESG would
approve them.  Stuff, by the way, that is often undocumented, so
that we have to rely on word of mouth and anecdotal information.

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.

Related to John's note below, it is interesting to observe that the
problem I have described causes _all three_ of the problems
that John described as "root problems".

Regards,
Charlie P.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jun 2003 21:14:32 +0200

Charlie,

clipping mercilessly from your message....

> 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 12:27:55 -0700

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:

> 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: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jun 2003 21:50:10 +0200

> I agree with your statements, and I wonder if you see the value

to put it this way - I see logic behind your argument, but can see your 
argument being used for conclusions that I wouldn't support....

> speaking) too complicated, about right, or not yet complicated

protocols should be "as simple as possible, and no simpler"... hard to 
tell....

> mean there has to be a killer app?  What about IPv6--?

no, I wouldn't place the bar that high.....

IPv6 is good for moving data that can be used to support a TCP session.
If there hadn't been a spec for using IPv6 to support TCP (and a spec for 
using IPv6 over Ethernet), I'd have said that the IPv6 protocol suite was 
incomplete.

                    Harald

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Jun 2003 16:02:59 -0400

--On Monday, 09 June, 2003 21:14 +0200 Harald Tveit Alvestrand 
<[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
> 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.
>...

Harald,

I would add one thing to this, which is that the description of 
a protocol that is to be approved on the basis that it does One 
Thing usefully must be quite clear about what that One Thing is. 
In other words, the narrower the focus of a protocol, the more 
important it is that its description describe what it is good 
for (and, if necessary, what it is not good for).  And that is 
an area in which I think we have fallen down on the job several 
times recently.

        john