IETF Logo Mail Archive

Re: Consensus? RFC1628 to Historic

Harald Tveit Alvestrand <Harald.Alvestrand@maxware.no> Thu, 30 July 1998 10:37 UTC

Delivery-Date: Thu, 30 Jul 1998 06:37:20 -0400
Return-Path: owner-ups-mib@CS.UTK.EDU
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA24914 for <ietf-archive@ietf.org>; Thu, 30 Jul 1998 06:37:18 -0400 (EDT)
Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA21219 for <ietf-archive@cnri.reston.va.us>; Thu, 30 Jul 1998 06:37:02 -0400 (EDT)
Received: from localhost (root@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id GAA12528; Thu, 30 Jul 1998 06:31:58 -0400 (EDT)
Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id GAA12521; Thu, 30 Jul 1998 06:31:55 -0400 (EDT)
Received: from alden ([10.128.1.25]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id MAA25335; Thu, 30 Jul 1998 12:27:53 +0200
Message-Id: <3.0.2.32.19980730113912.00fbc3f0@dokka.maxware.no>
X-Sender: hta@dokka.maxware.no
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Thu, 30 Jul 1998 11:39:12 +0200
To: "C. Adam Stolinski" <astolinski@worldnet.att.net>, Maria Greene <maria@xedia.com>
From: Harald Tveit Alvestrand <Harald.Alvestrand@maxware.no>
Subject: Re: Consensus? RFC1628 to Historic
Cc: IETF UPS-MIB <ups-mib@CS.UTK.EDU>
In-Reply-To: <01bdbb0a$4043e3a0$0d23480c@367140823worldnet.att.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:02 29.07.98 -0700, C. Adam Stolinski wrote:
>Hi Maria,
>
>Am I missing something????
>
>Historic is for something that is obsolete & not currently relevent.
>
>RFC 1628 is currently used by any number of UPS manufacturers and is a
>reference document in the new Universal Serial Bus Power Device Class.
>
>Why cannot the MIB progress as it is???????

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

v2.23.0 | Report a Bug | By Email