Re: resolving ambiguity in rfc1759 (standard printer MIB) [a proposal that won't require re-issuing a new rfc immediately]

"Thomas N. Hastings" <hastings@cp10.es.xerox.com> Mon, 15 May 1995 01:03 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05782; 14 May 95 21:03 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05778; 14 May 95 21:03 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa13881; 14 May 95 21:03 EDT
Received: from hpdmd48.boi.hp.com by hp.com with SMTP (1.37.109.15/15.5+ECS 3.3) id AA097709847; Sun, 14 May 1995 18:04:07 -0700
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP (1.38.193.5/15.5+ECS 3.4 Openmail) id AA01590; Sun, 14 May 1995 19:04:03 -0600
Received: from hp.com by hpbs987.boi.hp.com with SMTP (1.37.109.4/15.5+IOS 3.12) id AA25521; Sun, 14 May 95 18:57:28 -0600
Received: from alpha.xerox.com by hp.com with SMTP (1.37.109.15/15.5+ECS 3.3) id AA097139821; Sun, 14 May 1995 18:03:41 -0700
Received: from diana.cp10.es.xerox.com ([13.240.108.16]) by alpha.xerox.com with SMTP id <14430(1)>; Sun, 14 May 1995 18:01:07 PDT
Received: by diana.cp10.es.xerox.com (4.1/SMI-4.1) id AA01282; Sun, 14 May 95 18:01:03 PDT
Date: Sun, 14 May 1995 18:01:03 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Thomas N. Hastings" <hastings@cp10.es.xerox.com>
Message-Id: <9505150101.AA01282@diana.cp10.es.xerox.com>
To: dck2-iesg@mail.bellcore.com, jgyllens@hpbs3125.boi.hp.com
Subject: Re: resolving ambiguity in rfc1759 (standard printer MIB) [a proposal that won't require re-issuing a new rfc immediately]
Cc: case@snmp.com, pmi@hpbs987.boi.hp.com, waldbusser@ins.com

I have a proposal that wouldn't require that we publish a new rfc
immediately and would allow us to use the same OID now and in six months
for the prtConsoleDisable object:

   I propose that we change the enumerated INTEGER labels of the 
   prtConsoleInput enums to remove the ambiguity.

My proposal is feasible, since we have all mostly agreed to Joel's proposed
interpretation that enabled(3) means manual input accepted, and disabled(4)
means no manual input accepted (rather than the "double negative" 
interpretation).

Jeff Case has pointed out from the SNMP V2 rules (rfc 1442) that we can't
change the name of an object and can't change the DESCRIPTION (see Jeff's
mail attached).  However, according to rfc 1442 we can change the 
existing labels (or add new enumerations):

          An object definition may be revised in any of the following
          ways:

          (1)  A SYNTAX clause containing an enumerated INTEGER may have
               new enumerations added or existing labels changed.

So I propose that we clarify the ambiguity by adding words to the
enumeration labels, changing them from:

     enabled(3),
     disabled(4)

to:

     manual-input-enabled(3),
     manual-input-disabled(4)

Thus the new complete spec would be "clarified" (in six months with a new rfc
with any other editorial clarifications included) as follows:


--rfc1759:  prtConsoleDisable OBJECT-TYPE
--rfc1759:      SYNTAX     INTEGER {
--rfc1759new:                 manual-input-enabled(3),
--rfc1759new:                 manual-input-disabled(4)
--rfc1759:                 }
--rfc1759:      MAX-ACCESS read-write
--rfc1759:      STATUS     current
--rfc1759:      DESCRIPTION
--rfc1759:          "This object enables or disables manual input from the
--rfc1759:          operators console."
--rfc1759:      ::= { prtGeneralEntry 13 }


If we agree to the above, I suggest that the MIF could be fixed now using the
above longer enum labels.


I'd like feedback from those who implement management applications as to
whether this is just a "crock" that would confuse management application
users, since they might see the following as part of the UI menu:

      ConsoleDisable:  manual-input-enabled    x
                       manual-input-disabled

or would such a display be ok?  Or don't management applications display
exact transformations of what is in the Printer MIB anyway?

In other words, is it better to:

  (1) to fix this ambiguity immediately with a new rfc deprecating the 
  prtConsoleDisable object and adding a new prtConsoleManualInput object
  with the same DESCRIPTION:

        "This object enables or disables manual input from the
         operators console."

  or 

  (2) keep the current rfc and clarify in six month with a new rfc that
  changes the labels from enabled(3) and disabled(4) to 
  manual-input-enabled(3) and manual-input-disabled(4) (assuming
  that there will be other editorial clarifications or editorial changes, 
  such as new enum error codes (see Joel's and Harry's 22-Mar mail)?

If we can re-issue the rfc quickly (less than a month) and put the new rfc 
number (as well as the old into the Press Release), maybe we don't lose 
too much on publishing a new rfc.

Thanks,
Tom




--From jgyllens@hpbs3125.boi.hp.com Wed May  3 16:32:17 1995
--Return-Path: <jgyllens@hpbs3125.boi.hp.com>
--Received: from norman.cp10.es.xerox.com by diana (4.1/SMI-4.1)
--	id AA26320; Wed, 3 May 95 16:32:16 PDT
--Received: from alpha.xerox.com by norman.cp10.es.xerox.com (4.1/SMI-4.1)
--	id AA10543; Wed, 3 May 95 16:32:36 PDT
--Received: from hp.com ([15.255.152.4]) by alpha.xerox.com with SMTP id <14951(4)>; Wed, 3 May 1995 16:31:59 PDT
--Received: from hpdmd48.boi.hp.com by hp.com with SMTP
--	(1.37.109.15/15.5+ECS 3.3) id AA185425437; Wed, 3 May 1995 08:37:18 -0700
--Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
--	(1.38.193.5/15.5+ECS 3.4 Openmail) id AA08399; Wed, 3 May 1995 09:35:45 -0600
--Received: from hpbs4703.boi.hp.com by hpbs987.boi.hp.com with SMTP
--	(1.37.109.4/15.5+IOS 3.12) id AA28236; Wed, 3 May 95 09:29:45 -0600
--Received: by hpbs3125.boi.hp.com
--	(1.37.109.8/15.5+IOS 3.22) id AA22380; Wed, 3 May 1995 09:35:29 -0600
--From: Joel Gyllenskog <jgyllens@hpbs3125.boi.hp.com>
--Subject: resolving ambiguity in rfc1759 (standard printer MIB)
--To: dck2-iesg@mail.bellcore.com
--Date: Wed, 3 May 1995 08:35:28 PDT
--Cc: case@snmp.com, pmi@hpbs987.boi.hp.com, waldbusser@ins.com
--Mailer: Elm [revision: 70.85]
--
--To:    Deirdre Kostick, IESG management area director
--CC:    Jeff Case, who suggested that I contact you
--       Steve Waldbusser, technical advisor to printer working group
--       Members of the printer working group
--From:  Joel Gyllenskog, chair of the printer working group 
--Re:    Ambiguity in prtConsoleDisable object
--
--Deirdre,
--
--On March 21, 1995, the printer MIB was issued as rfc1759.  We tried to
--produce a perfect document.  In the process of implementing the rfc,
--another engineer and I disagreed on the meaning of object
--prtConsoleDisable.  Below is the text taken from rfc1759 that is
--the source of this disagreement.
--
--rfc1759:  prtConsoleDisable OBJECT-TYPE
--rfc1759:      SYNTAX     INTEGER {
--rfc1759:                     enabled(3),
--rfc1759:                     disabled(4)
--rfc1759:                 }
--rfc1759:      MAX-ACCESS read-write
--rfc1759:      STATUS     current
--rfc1759:      DESCRIPTION
--rfc1759:          "This object enables or disables manual input from the
--rfc1759:          operators console."
--rfc1759:      ::= { prtGeneralEntry 13 }
--
--When I became aware of this potential ambiguity I sought feedback from
--the group as to their interpretation of the meaning of the values shown.
--Sure enough, respondants were divided as to their interpretation of the
--meaning of the value for the object.
--
--Since the rfc was already issued, and since it took f-o-r-e-v-e-r to 
--make that happen, I was in a quandry.  HP and other vendors are in the
--process of producing products that will suport the printer MIB.  The
--tyranny of product schedules is horrid.  Feeling that there wouldn't be
--an opportunity to change anything in the rfc for at least 6 months, I
--proposed to the working group that we agree what would happen when
--"prtConsoleDisable" had a value of "enabled" and what would happen when
--"prtConsoleDisable" had a value of "disabled".  This effort was 
--reasonably successful.  
--
--This morning I read mail from Jeff Case.  He suggested that we should
--seek a speedy but official solution.  His understanding is that it would
--be illegal for us to chanage the name from "prtConsoleDisable" to 
--something like "prtConsoleInputStatus", and he quoted chapter and verse
--from rfc1442 pp41ff.  I believe that he may have already sent you a copy
--of that communication.  If not let me know and I'll be happy to send it
--along.
--
--Based on his message I am asking if it is possible for us to:
--
--1.  Deprecate prtConsoleDisable by changing its status from "current" to
--    "obsolete".
--2.  Add an object named "prtConsoleInputStatus" which has an new OID
--    but otherwise looks like the old "prtConsoleDisable" object.
--3.  Republish the MIB.
--
--Your prompt response would be greatly appreciated.  
--
--Joel
--





Jeff Case's mail:

From case@snmp.com Tue May  2 21:57:57 1995
Return-Path: <case@snmp.com>
Received: from norman.cp10.es.xerox.com by diana (4.1/SMI-4.1)
	id AA23927; Tue, 2 May 95 21:57:56 PDT
Received: from alpha.xerox.com by norman.cp10.es.xerox.com (4.1/SMI-4.1)
	id AA09389; Tue, 2 May 95 21:58:17 PDT
Received: from hp.com ([15.255.152.4]) by alpha.xerox.com with SMTP id <14445(5)>; Tue, 2 May 1995 21:57:44 PDT
Received: from hpdmd48.boi.hp.com by hp.com with SMTP
	(1.37.109.15/15.5+ECS 3.3) id AA157027041; Tue, 2 May 1995 21:57:21 -0700
Received: from hpbs987.boi.hp.com by hpdmd48.boi.hp.com with SMTP
	(1.38.193.5/15.5+ECS 3.4 Openmail) id AA10752; Tue, 2 May 1995 22:56:27 -0600
Received: from hp.com by hpbs987.boi.hp.com with SMTP
	(1.37.109.4/15.5+IOS 3.12) id AA27526; Tue, 2 May 95 22:50:32 -0600
Received: from seymour4 (seymour4.snmp.com) by hp.com with SMTP
	(1.37.109.15/15.5+ECS 3.3) id AA155196978; Tue, 2 May 1995 21:56:18 -0700
From: case@snmp.com
Received:  by seymour4 (5.61++/2.8s-SNMP )
	id AA21365; Wed, 3 May 95 00:49:13 -0400
Date: Tue, 2 May 1995 21:49:13 PDT
To: rturner@jrtsparc5.rd.qms.com
Subject: Re: prtConsoleDisable - request for concensus
Cc: pmi@hpbs987.boi.hp.com

>Of course...not being able to change "just" the name would mean we would
>have to deprecate the original OID (I'm assuming that's what you mean
>by "blow away the old one, Jeff).


i'm sorry, it is late, and i was too terse for a mailing list that is not
chock full of ``snmp weenies'' but you got exactly the correct meaning

to quote the chapter and verse from the v2 smi (the document that regulates
mib definitions) found in rfc 1442 pp 41ff:

          10.  Extending an Information Module

          As experience is gained with a published information module,
          it may be desirable to revise that information module.

<<<jdc comment -- i think we recently "gained" experience>>>

          To begin, the invocation of the MODULE-IDENTITY macro should
          be updated to include information about the revision.
          Usually, this consists of updating the LAST-UPDATED clause and
          adding a pair of REVISION and DESCRIPTION clauses.  However,
          other existing clauses in the invocation may be updated.

          Note that the module's label (e.g., "FIZBIN-MIB" from the
          example in Section 5.8), is not changed when the information
          module is revised.


          10.1.  Object Assignments

          If any non-editorial change is made to any clause of a object
          assignment, then the OBJECT IDENTIFIER value associated with
          that object assignment must also be changed, along with its
          associated descriptor.

<<<jdc -- ok, so the question is it editorial? or is it not?>>>
<<< editorial changes are ok without blowing an object away and starting over>>>
<<< but you cant make non-editorial changes to an existing object, i.e., >>>
<<< non editorial changes are not ok  >>>
<<< keep reading >>>


          10.2.  Object Definitions

          An object definition may be revised in any of the following
          ways:

          (1)  A SYNTAX clause containing an enumerated INTEGER may have
               new enumerations added or existing labels changed.

          (2)  A STATUS clause value of "current" may be revised as
               "deprecated" or "obsolete".  Similarly, a STATUS clause
               value of "deprecated" may be revised as "obsolete".
<<< so we can blow an object away>>>

          (3)  A DEFVAL clause may be added or updated.

          (4)  A REFERENCE clause may be added or updated.

          (5)  A UNITS clause may be added.

          (6)  A conceptual row may be augmented by adding new columnar
               objects at the end of the row.

          (7)  Entirely new objects may be defined, named with
               previously unassigned OBJECT IDENTIFIER values.
<<<and we can create new ones that may be similar, but with different oid's>>>

          Otherwise, if the semantics of any previously defined object
          are changed (i.e., if a non-editorial change is made to any
          clause other those specifically allowed above), then the
          OBJECT IDENTIFIER value associated with that object must also
          be changed.

<<<pay careful attention below>>>
          Note that changing the descriptor associated with an existing
          object is considered a semantic change, as these strings may
          be used in an IMPORTS statement.
<<<sigh, you are dead meat -- it speaks directly to the issue and as to why>>>

          Finally, note that if an object has the value of its STATUS
          clause changed, then the value of its DESCRIPTION clause
          should be updated accordingly.

you may or may not like the above rules (although i might add that they
are exceptionally well written by an exceedingly informed, handsome, and
modest set of authors) but, more seriously, they have been crafted as a
result of multiple years of experience with defining mibs and subsequently
revising them -- and it has been learned (the hard way) that this discipline
is necessary if there is to be interoperability with multiple versions of
a time-variant mib

furthermore, since we are working on a standards-track document,
these rules are the law of the land and we must follow them

therefore, i suggest it is time for us to ask our chair (joel) to plead our
case with dck (deirdre kostick) who is now the relevant area director for
management within the ietf (having replaced marshall rose when his term ended
in april)

i was hoping somebody would speak to this issue before now so that i wouldn't
have to be the "heavy"

i was the chair of the ups mib working group ... there were similar
editorial screwups, we didn't fix them ... we're still paying for that

i recommend you republish if you can -- deirdre is still early in the job
but my experience with her over the past several years is that neither her bark
nor her bite are especially fearsome

if you aren't able to republish, it isn't the end of the world

regards,
jdc