Re: draft-ops-endpoint-mib-04.txt

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Keith McCloghrie writes:

Keith> This MIB caused us some confusion this week.  Somebody wanted a
Keith> TC for generic Internet-layer addresses.  We naturally thought
Keith> of this end-point MIB.  Unfortunately, they had the possibility
Keith> of needing IPX addresses which are not supported by
Keith> draft-ops-endpoint-mib-03.txt.  The closest they could find for
Keith> TCs in a standard MIB, which met their needs, was the
Keith> InternetworkAddr and InternetworkAddrType TCs defined in

Keith> ftp://ftp.atmforum.com/pub/approved-specs/af-mpoa-0092.000.pdf

Keith> The InternetworkAddrType TC defined there is more
Keith> general-purpose in that it's an enumerated value based on
Keith> "Address Family Numbers" as assigned by IANA (see
Keith> http://www.iana.org/numbers.html#A).  Was there ever any
Keith> thought of using this more general mechanism for the
Keith> draft-ops-endpoint-mib-xx MIB ?

Your question is whether we should focus on IP addresses only (which
we currently do) or whether we should try to support arbitrary network
layer addresses. We have certainly thought about this option. But we
decided to focus on just IP addresses because

 (a) this is what the charter says the design team has to do;

 (b) only few IETF MIBs really need to support arbitrary network
     addresses (RMON2 uses plain OCTET STRINGS, FLOW-METER-MIB defines
     its own PeerAddress TC) while much more MIBs use IP addresses
     (even though some actually kind of misuse them since they really
     want transport addresses);

 (c) most MIBs for network layers are specific to network layer
     technologies and they naturally have their own TCs to represent
     addresses (e.g. AtmAddr) and they won't benefit from a general
     network layer address TC;

 (d) supporting arbitrary network layer address types means that we
     will see regular updates and thus the whole TC MIB would benefit
     from IANA control rather than sitting in a standards track RFC.

This is what I recall without re-reading the archive. There might have
been other reasons I am missing right now. I do not claim that this
was the right or wrong decision - I am just trying to explain how we
got to where we are right now.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>