Subject: RE: [newtrk] Comments on draft-klensin-newtrk-std-repurposing-00. txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 6 Sep 2004 11:18:38 -0700

> And of whether the hypothesis of interoperability has actually
> been tested, in implementation and in deployment, rather than
> being merely an assertion.  IMO, it would be bad to lose sight
> of that particular part of the definitions.

Addressing this seriously would require the IETF to move to
the practice of holding interops. We have done this extensively
in OASIS with the Web Services security stack and others.

> While I understand the reasons why we moved away from making
> statements about "optional", "recommended", "mandatory", etc., I
> believe they have had an unintended side effect.  As I
> understand it, your point --and that of Erik and Brian-- is
> that, traditionally, the IETF Standards Track is about clarity
> of specification, implementability, and interoperability.  It is
> much less, if at all, about recommendations of ultimate
> goodness, especially if there is deployed existing practice that
> is viewed as successful by someone.   

The problem I have here is how is ultimate goodness to be 
measured and by whom?

The NOMCON process is not something I would use to select
people who are to act as supreeme arbiters of goodness for
the industry. 

> >From that particular perspective, "std-repurposing" and
> "antiques" are two aspects of the same issue.  The first would
> actually permit the community to say, for the first time since
> we got rid of the possibility of "standard but not recommended"
> --and much more clearly-- "look, this protocol stinks because...
> but it is widely deployed, the specification describes it
> adequately, and there are lots of interoperable implementations
> out there".  The importance of that seems to become more obvious
> with each passing month.

It sounds fine in the abstract but what are the concrete 
implications?

It would be very good if the IETF was proactively comming out
and saying things like 'spam is a real problem in SMTP, we 
have to deal with it', the problem has been real for at least
a decade.

Or if we are talking about dreadful protocol design, NNTP
chews at least 10,000 times more bandwidth than it should.
Flood fill has had its day.

What I suspect is more likely to happen is that the 'bad
design' issues that would mostly exercise people would be
the type of stuff where the IETF has got it dead wrong.
The  IETF got it dead wrong on firewalls and NAT and
it got it dead wrong on BEEP.

The problem is not just that the criteria for goodness
are not written down. The problem is that the IETF is
run in the manner of the early medieval church before 
power was consolidated in the papacy.

What is at risk here is that a new way is invented of playing
the old game of 'People are not wanting to deploy my spec, 
so I am going to make my spec a precondition for deployment
of your spec that looks more popular'.

		Phill 
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html