Here is the 8/21/97 mail to the PWG that I think you are referring to from
Harald. Correct? At the end he says:
>I've scheduled the Job MIB on my list of things to look at; let's hope
>things get sorted out correctly!
But I think that he hasn't.
He also lists several reasons why he thinks the IESG wouldn't standardize
things:
>The IETF should, IMHO, NOT standardize things in the following cases:
>
1. >- The proposal is not going to be used in or around the Internet
2. >- The proposal cannot be evaluated by IETF experts for lack of competence
3. >- The proposal cannot be modified if the IETF community thinks that it
> needs modification
4. >- The proposal does not fit with IETF policy
>
>The last one is a flexible point again; some examples include requiring
use of
>patented or encumbered technology when freely available alternatives
>exist, mandating use of cleartext passwords, standardizing very complex
>protocols when simpler solutions solve most of the problem.
>It's a judgment call.
It would be helpful to know which of the above reasons applies to the
Job Monitoring MIB [I've added numbers to them]
Discussion about reason 1 (The proposal is not going to be used in or
around the Internet):
MIBs in general are still being standardized by the IETF, if they have
to do with network management, i.e., with keeping the Internet
(and intranets) running.
The problem is that neither the Printer MIB nor the Job Monitoring MIB
help with keeping the network itself running, they are MIBs involving
the hosts at the end points. Same for the Host Resources MIB (which
has been re-activiated because the Printer MIB needs it).
However, the Printer MIB and the Host Resources MIB do seem to be
still on the IETF standards track.
Discussion about reason 2 (The proposal cannot be evaluated by IETF experts
for lack of competence):
David Perkins did a 5 hour detailed review. We incorporated all his
suggestions, except for the one he felt was the most important one
(split the attribute table into two tables, one for the integer values
and one for the string values). We felt there was some value to have
the two together in the same table, since there are a number of
attributes that have both integer and string representations.
Discussion about reason 3 (The proposal cannot be modified if the IETF
community thinks that it needs modification):
The JMP project has no problem with making any changes suggested by
the IETF (except see reason 2).
Discussion about reason 4 (The proposal does not fit with IETF policy):
Perhaps the current policy is "no more application MIBs"
and the Job Monitoring MIB is an application MIB?
Tom
At 16:33 11/06/1997 PST, Chris Wellens wrote:
>
>
>
>
>On Thu, 6 Nov 1997, Harry Lewis wrote:
>
>>
>> I'm having a difficult time understanding why the Job MIB is not
chartered and
>> would like an explanation.
>
>I went back through the email archives and found what I think
>was intended to be the definitive answer. See the email
>sent by Harald Alvestrand to the PWG mailing list that is dated
>8/21/97.
>
>
>Return-Path: <pwg-owner@pwg.org>
>From: Harald.T.Alvestrand@uninett.no
>To: JK Martin <jkm@underscore.com>
>Cc: pwg@pwg.org
>Subject: Re: PWG> The Printer Working Group as its own standards body
>Date: Thu, 21 Aug 1997 01:02:06 PDT
>Sender: owner-pwg@pwg.org
>
>Jay,
>good points.
>
>The relationship between the IETF and non-IETF groups has always been
>worrisome; in some cases, we have seen things that looked as if someone
>outside the IETF wanted to use the IETF as a tool to get the "community"
>to endorse a position that couldn't be sold on its own merits, AND place
>the IETF in a position where it couldn't insist on obvious weaknesses
>in the protcol being repaired.
>The discussions around Sun RPC and NFS focused around this issue; it is
>also one of the things currently making the S/MIME debate so strident.
>
>In other cases, the IETF community knows that it does not add significant
>value to the process of getting a standard done; the IETF is aggressively
>uninterested in specifying the number of pins on serial plugs or the
>precedence of operators in the C language, to name two instances, although
>both efforts are obviously important to our user community.
>Recent instances are our non-involvement in the SET payment protocol and
>our closing down of work on HTML.
>(This is of course a fluid point, since the set of people in the IETF
>community,
>and therefore its expertise, changes over time - after all, the IPP *is*
>part of the IETF community.)
>
>The standards process is the process the IETF has that places a stamp
>of approval on specifications. Obviously, we have to be careful what we
>use it for.
>
>The IETF should, IMHO, NOT standardize things in the following cases:
>
>- The proposal is not going to be used in or around the Internet
>- The proposal cannot be evaluated by IETF experts for lack of competence
>- The proposal cannot be modified if the IETF community thinks that it
> needs modification
>- The proposal does not fit with IETF policy
>
>The last one is a flexible point again; some examples include requiring
use of
>patented or encumbered technology when freely available alternatives
>exist, mandating use of cleartext passwords, standardizing very complex
>protocols when simpler solutions solve most of the problem.
>It's a judgment call.
>
>Since the bandwidth of those who have to do the judging (the IESG) is
limited,
>and since we know we're not infallible, we don't want this process to limit
>publication of documents, even though we don't necessarily agree with them.
>
>Therefore, RFC publication, which has a reputation as a stable reference,
>is available for non-IETF documents in "informational" form. We sometimes
>ask for review of informationals, but only attempt to block publication of
>them when we regard the content as misleading (such as labelling itself
>"Internet Standard") or that publication would lead to confusion in the
>community (such as having a fight about 2 approaches in a WG, and the
>"loser" being published before the "standard").
>
>I've scheduled the Job MIB on my list of things to look at; let's hope
>things get sorted out correctly!
>Regards,
>
> Harald T. Alvestrand
>
>
>
>
>
>