Subject: Re: Consensus? RFC1628 to Historic -Reply

From: Ron Pitt <[email-masked]>
Date: Mon, 03 Aug 1998 10:56:22 -0400

>>> "C. Adam Stolinski" <[email-masked]> 07/30/98 08:58am
>>>
> I had no idea that the IETF had become another "Alice in Wonderland"
> spec group!
>
> Is it about standards for implementation - or about busying ourselves
> with "workgroups"???
>
> RFC 1628 works, is implemented by the entire UPS industry, and
> nobody feels that it needs any changes.  So, the IETF position is lets
> make it obsolete, because there is no activity in the WG?????
>
> There is a difference between "work" and "makework".
>
> "If it ain't broke, don't fix it."
>
> Regards,
> Adam

I'll second that.

Regards,
Ron Pitt

-----Original Message-----
From: Harald Tveit Alvestrand <[email-masked]>
To: C. Adam Stolinski <[email-masked]>; Maria Greene
<[email-masked]>
Cc: IETF UPS-MIB <[email-masked]>
Date: Thursday, July 30, 1998 3:32 AM
Subject: Re: Consensus? RFC1628 to Historic

>The formalist AD steps in to explain IETF procedures
>
>In order for a document to progress to Draft Standard (the next step
for
>the UPS MIB), the IETF rules (RFC 2026) require:
>
>- Documentation that all objects have in fact been implemented by
>  at least 2 independent implementations (this is to verify that the
>  specs are clear enough to implement from)
>
>- WG consensus that there are no objects that need to have their
>  definitions updated, or should be deprecated or declared obsolete
>  (MIB rules say you can't delete things, only make them obsolete)
>  Or a new draft that has those changes, if the WG deems it required.
>  (New functionality needs to be a separate document)
>
>This translates to "the WG must do work".
>If nobody is willing to spend time and effort in doing this, there
>is probably no reason to keep the spec on the IETF Standards Track.
>
>
>
>Harald Tveit Alvestrand
>IETF Area Director, Operations and Management
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 03 Aug 1998 20:24:35 +0200

>> "If it ain't broke, don't fix it."

The essence of why the IETF standards track is a multistage process:

If there is nobody willing to document whether it is broken or not,
the IETF doesn't want to take the responsibility for claiming that it
is not broken.

We seem to have consensus that nobody's willing to take the time to
document that it's not broken. That's a reasonable solution.

                             Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]