Re: Why was NsapAddress included in SMP SMI?

Marshall Rose <mrose@dbc.mtview.ca.us> Wed, 23 September 1992 03:16 UTC

To: mlk%bir.UUCP@mathcs.emory.edu
Cc: snmp2@thumper.bellcore.com
Reply-To: snmp2@thumper.bellcore.com
Subject: Re: Why was NsapAddress included in SMP SMI?
In-Reply-To: Your message of "Tue, 22 Sep 1992 22:25:33 EST." <0D15DDF1.eajes6@bir.bir.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 22 Sep 1992 20:19:11 -0700
Message-Id: <22562.717218351@dbc.mtview.ca.us>
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: Marshall Rose <mrose@dbc.mtview.ca.us>

> Why was NsapAddress included in SMP SMI?  I assume IpAddress had to
> stay there for compatibility with the existing base of implementations.

Although it might seem that NsapAddress was put in there as a doggie
biscuit for any OSI types who might be on the SNMP version 2 committee,
there is an experimental RFC, the CLNS MIB, which uses an NsapAddress
type.  So, it was kept for compatiblity with that.

Yes, you are absolutely right about IpAddress.

> Most of the SMP documents (excluding Transport Mappings for SMP) are
> address and transport independent.

Yes, just the way it was planned.

> What happens when some other group wants there address typed in SMI?

They define a textual convention.

> Maybe Transport Mappings module would be a better place to define
> these new address types?

Uh, "these new address types".  There is only one new one in the SMI
document, it's NsapAddress.  The rest are all in the TM document.  

If you want to suggest we bag NsapAddress, I don't think anyone would
really put up a big fight considering that I know of only one
implementation of that CLNS MIB.  (There may be others though.)

/mtr

Re: Why was NsapAddress included in SMP SMI? Marshall Rose