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 -0700
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
- Re: resolving ambiguity in rfc1759 (standard prin… Thomas N. Hastings
- Re: resolving ambiguity in rfc1759 (standard prin… Don Wright
- Re: resolving ambiguity in rfc1759 (standard prin… Thomas N. Hastings