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

[Keith McCloghrie <kzm@cisco.com>]

Thanks for explaining how we got here.  In addition to the ones you
list, the other activities which need support for a larger set of
network addresses are ION, MPLS (and MPOA in the ATM-Forum).  Note that
these need only a specific set, not the arbitrary set you indicate in
your point d) below.

In generating this response, I went looking for the ION and MPLS MIBs,
and here's what I found: the work item you identify in point d) below
has already been undertaken by IANA.  Here's a quote from RFC 2677:

   5.  IANA Considerations
 
   The Internet Assigned Numbers Authority (IANA) has been and continues
   to be responsible for maintaining the ADDRESS FAMILY NUMBERS
   (http://www.isi.edu/in-notes/iana/assignments/address-family-numbers)
   name space assignments.  The IANA has placed this list in a MIB
   module, such that it may be imported into other MIBs.  The motivation
   for doing this is to allow MIBs to not have to change when a new
   assignment is made to the ADDRESS FAMILY NUMBERS.  This is very
   similar to the motivation behind the IANAifType-MIB.
 
   Any additions or changes to the list of ADDRESS FAMILY NUMBERS
   registered via IANA will be done as they have in the past and this
   document does not propose any changes to the ADDRESS FAMILY NUMBERS
   other than to place them into a MIB, which can be found via anonymous
   FTP at: ftp://ftp.isi.edu/mib/ianaaddressfamilynumbers.mib.
 
Note that the above quote has been copied verbatim into
draft-ietf-mpls-ldp-mib-03.txt (and a similar TC was defined in
draft-srinivasan-mpls-te-mib-01.txt).

Given the above, I now think that InetAddressType should be deleted
from this MIB, and the AddressFamilyNumbers TC from 
IANA-ADDRESS-FAMILY-NUMBERS-MIB should be IMPORTed and used instead,
This will promote greater consistency across IETF MIBs.

Keith.


> 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/>
> 
> 
> 
>