Discipline of Internet Protocol Engineering

Jari Arkko jari.arkko at piuha.net
Wed Jun 4 12:02:07 CEST 2003

Keith Moore wrote:

> The reason I say this is that several groups have demonstrated the inability
> to define the problem they are working on,

Dave Crocker wrote:

> Unfortunately, i think this problem is deeper than we might wish to
> acknowledge.  I tend to be a charter fascist, on the theory that a
> crystal clear charter will leave no doubt about the problem being
> solved, and/or the benefit to be derived from the result and the
> deliverables to be produced.

> I view charters as real contracts, making clear what is included and
> obligated and what is excluded and prohibited.
> However with great regularity, remarkably fuzzy charters are getting
> approved. since chartering involves lots of experienced people beyond
> the working group, we can't simply assess the problem on the working
> group folk.

John Loughney wrote:

> I would say that there is a breakdown in the chartering process. 

Hmm... I think that the problem is even deeper than you three
wish to acknowledge ;-) I'm sure there are quality differences
in charters. And that can be improved upon. However, I believe
there's a more fundamental reason why some charters are or may
need to be fuzzy. That reason has to do with the timing when
the IETF gets involved, or the scope of the problem. Are you
doing adding a new algorithm to an existing security protocol?
Pretty specific. Are you going to develop a protocol for a specific
purpose? Still pretty simple. Are you going to develop a whole
set of protocols and extensions to fulfill a function. Starting
to get more complex (example: SIP). Are you going to re-architect
IPn and develop IPn+2? Pretty tough... And the timing -- have
just realized a problem? Or are we at a stage where someone
else has realized the problem, and is bringing to the IETF
solution proposals, or even proposed protocols that we could
standardize? Of course, we could define the IETF as the organization
that only takes on very specific work, and only if there's
advanced protocol work and deployment experience from vendors
with the new work... not sure that would satisfy everyone.


More information about the Problem-statement mailing list