Subject: Re: An action plan for pushing the SMI to Standard

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 18 Jun 1998 14:20:34 -0700 (PDT)

Hi Bob,

On Thu, 18 Jun 1998, you wrote:

bob> >At 07:54 AM 6/18/98 -0600, bok wrote:
bob>
bob> <...>
bob> >Overall, I see two alternatives:
bob> >
bob> >   1. a TC approach such as Dave Perkins has been investigating
bob> >      w.r.t. wrapping the new data types in OPAQUE;
bob>
bob> Shudder [wrt OPAQUE].  On the surface, that looks potentially messy.
bob> Under the surface...it looks a lot worse.  It is a clever idea, I
bob> agree...but clever doesn't always equate to good.

I feel very strongly that we need to do something about the problem that
Juergen so eloquently pointed out --

Juergen> [The fundamental problem here is that the RFCs do no specify a "gentle
Juergen> way" to handle unknown tags, e.g. by saying thy should be handled as
Juergen> opaque values.]

Without addressing this problem in some way it is not possible to add new
base types to the SMI without changing the protocol at the same time.

The deployment headaches that would result from changing the protocol
to accept new tags are likely to be much worse than mere annoyances:
there could be "black hole" communication failures if the protocol
version number were not changed (messages dropped by older implementations
which get ASN.1 parse failures), but on the other hand changing the version
number (and supporting multiple versions during a transition) is not
without significant cost.

Letting new types hide behind an Opaque tag, on the other hand, _will_
allow new types to be added without changing the protocol, because the
current protocol(s) all recognize Opaque as a valid (although disgusting)
type.  Of course, this idea won't work well unless the SMI is changed
so that the stuff hiding behing the Opaque tag is well-defined.  But
that is a change which can be deployed incrementally, and which I think
can be done at much less cost than supporting a new protocol version.

I will concede that hiding stuff behind an Opaque tag is rather ugly.

In hindsight, defining the protocol so that unknown application tags are
skipped rather than causing ASN.1 parse errors might have been a better
idea.  But it is too late for that.

I, for one, fail to see why this idea has met with such an unfavorable
reception.  It seems to me to be a practical and relatively low-cost
solution to a real problem, and I think that outweighs it ugliness.

If there is something I am missing please feel free to correct me.

Thanks,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "Abhay Shriramwar" <[email-masked]>
Date: Thu, 18 Jun 1998 10:38:20 PDT

I agree with interoperability and support to existing SMI must be 
important consideration.

Thanks

regards
Abhay S.

>From [email-masked] Thu Jun 18 04:13:56 1998
>Received: (daemon@localhost) by bubbuh.cisco.com 
(8.8.4-Cisco.1/CISCO.GATE.1.1) id BAA07499 for Rmonmib-outgoing; Thu, 18 
Jun 1998 01:39:16 -0700 (PDT)
>Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com 
[198.92.30.31]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with 
ESMTP id BAA07494 for <[email-masked]>; Thu, 18 Jun 1998 
01:39:13 -0700 (PDT)
>Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by 
hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id BAA07223; 
Thu, 18 Jun 1998 01:39:11 -0700 (PDT)
>Received: (from smap@localhost)
>	by proxy1.cisco.com (8.8.7/8.8.5) id BAA12064;
>	Thu, 18 Jun 1998 01:39:09 -0700 (PDT)
>Received: from ra.ibr.cs.tu-bs.de(134.169.34.12) by proxy1.cisco.com 
via smap (V2.0)
>	id xma012016; Thu, 18 Jun 98 08:39:01 GMT
>X-SMAP-Received-From: outside
>Received: from henkell.ibr.cs.tu-bs.de (henkell [134.169.34.191])
>	by ra.ibr.cs.tu-bs.de (8.8.6/8.8.6) with ESMTP id KAA17004;
>	Thu, 18 Jun 1998 10:38:42 +0200 (MET DST)
>Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de 
(8.7.6/tubsibr) id KAA06419; Thu, 18 Jun 1998 10:38:19 +0200
>Date: Thu, 18 Jun 1998 10:38:19 +0200
>Message-Id: <[email-masked]>
>From: Juergen Schoenwaelder <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked], [email-masked],
>        [email-masked], [email-masked], [email-masked]
>In-reply-to: <[email-masked]> 
(message from
>	Bob Stewart on Wed, 17 Jun 1998 14:31:27 -0400)
>Subject: Re: An action plan for pushing the SMI to Standard
>References: <[email-masked]> 
<[email-masked]>
>Mime-Version: 1.0 (generated by tm-edit 7.106)
>Content-Type: text/plain; charset=US-ASCII
>Sender: [email-masked]
>Precedence: bulk
>
>
>>>>>> Bob Stewart writes:
>
>Bob> I don't see why having a new tag is any more traumatic than
>Bob> special-casing an old one.  If anything I'd think a new tag would
>Bob> be cleaner and easier to implement.
>
>Bob> Without a new tag smart, helpful, general-purpose applications
>Bob> will mishandle 64-bit integers or unsigned, thinking they're
>Bob> counters and require calculating a delta.  In other words,
>Bob> special counter semantics go with the existing tag.  To use it as
>Bob> a 64-bit unsigned integer violates that.
>
>I agree that a new tag would be clean, relatively easy to implement
>and avoid ambiguities in cases where the SNMP manager is not capable
>to understand or simply does not have access to the relevant MIBs.
>
>Bob> With a new tag we maintain a consistent, protocol-level
>Bob> distinction, and in *both* cases it works only between
>Bob> consenting, upgraded agents and applications.
>
>The down-side of a new tag is that an agent which implements
>Unsigned64 will cause a manager which does not implement Unsigned64 to
>get an ASN.1 parse error. In other words: you would not be able to
>`walk' the "new" agent with an "existing" SNMPv2c/SNMPv3 manager.
>Adding a tagged Unsigned64 causes interoperability problems, even if
>this is the solution we really really really like to have.
>
>[The fundamental problem here is that the RFCs do no specify a "gentle
>way" to handle unknown tags, e.g. by saying thy should be handled as
>opaque values.]
>							Juergen
>
>Juergen Schoenwaelder  [email-masked] 
http://www.cs.tu-bs.de/~schoenw
>Technical University Braunschweig, Dept. Operating Systems & Computer 
Networks
>Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 
391 3283)

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com