Subject: Re: complex extensions attacking IETF protocols

From: "Marshall Rose" <[email-masked]>
Date: Mon, 2 Nov 1998 19:05:13 -0800

hi. i agree with your concern, but i think we are talking truisms here.

> The IETF traditions of simple protocols, interoperability and design for
> technical excellence rather than personal/company benefit have resulted in
> keeping implementation barriers for a new service reasonably low.  But
> such a principle has never been a formal part of IETF tradition.

i don't know how well the terms "formal" and "IETF tradition" mix.

nonetheless, while there may be exceptions to the rule, i think that the
more experienced IETF folk (yourself included) have always tried to provide
guidance that a protocol should solve 90% of the problem as simply as it can
(and then remove the other 10% from the problem requirements).

> I believe
> we should add "keep implementation barriers for a new service low" as a
> tradition on-par with the others in the IETF.  An attack on this principle
> could undermine the other related IETF principles over time.

Too late! An observer with a substantive institutional history might observe
that as the IETF has become more inclusive the engineering quality of the
work product isn't quite what it used to be, say since the design of IP/TCP.
This appears to be a necessary trade-off for openness.

> I also believe IETF participants should be alert to _individuals_ in the
> IETF who are deliberately increasing the complexity of IETF protocols
> contrary to the best technical design.

Too late! To name just one instance, remember the CMOT v. SNMP skirmishes of
the late 80's? Both camps were absolutely convinced that they each had a
superior technical design.

The problem is that an open process allows for judgement calls as to
engineering quality and feature necessity. For example, today the IESG
issued a last call on an extension mechanism for POP.  My judgement is that
the technical design of POP would be improved if we removed a few things
that I put into it 12 years ago. Instead we're giving people a way of
advertising stuff that they added to their implementation. But, the IESG's
judgement is different (and they did ask for my input some months ago), so
I'll live with it.

So, you are asking that the IETF exercise vigilence in practicing good
engineering principles. I agree.

/mtr

> ...
> ** The XXXXXXX was the name of a specific product which I do not consider
> revelent to this forum.

You left off two X's in the name. Ooops, I was thinking you meant the vendor
name not the product name!

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 3 Nov 1998 11:18:23 +0100

At 19.05 -0800 98-11-02, Marshall Rose wrote:
>For example, today the IESG

I did ask for your (and others) input, and I thank you for it. Your opinion 
was clear :-) so we do not talk about confusion from my side.

But, my descision as AD was that the POP3 protocol is so confusing today 
for clients, because of the "optional" features the server can have even 
using the basic POP3 document. For example, the server can implicitely 
delete the mail after a mail is read, at a quit, even without an explicit 
DELE command.

Because of these existing practices, I made the descision that there must 
be a way for a client to know what policy the server uses for optional 
features.

So, yes, this expands the POP3 protocol, but it at the same time make (I 
think) the protocol more robust from an operational perspective, and no, it 
does not at all say that future extension will even be considered.

There is an IESG note which states this, i.e. that no more extensions will 
be accepted.

Because of all of this, I have recommended IESG to advance this POP3 
extension to an RFC.

    Patrik

------------------------------------------------------------------
Area Director, Applications Area               Email: [email-masked]
IETF                                             URL: http://paf.se
                                          PGP Key ID: 0xBD236602

   In theory there is no difference between theory and practice,
   but in practice, there is.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 3 Nov 1998 11:18:23 +0100

Patrik