Subject: Re: ipNetToMediaPhysAddress

From: [email-masked]
Date: Thu, 20 Nov 97 10:44:27 EST

Paul,

>kennethw> When this was discussed in March we decided to require the
>kennethw> MIB to externalize E.164 addresses using the BCD encoding
>kennethw> in order to be consistent with the other MIBs being
>kennethw> developed in the IETF. I think that internally E.164
>kennethw> addresses can be sent in native encoding.  This was debated
>kennethw> on the list.

>Now I'm more confused.

>Apart from MIB access, the addresses appear only in two places: ATM
>signalling, and ARP messages.  In both, the BCD encoding is used.
>(And if you asked a signalling expert what the term "E.164 address
>native encoding" means to him, I'd expect you would be told either
>"nothing" or "BCD".  Certainly not ASCII.)

>So given that the ASCII encoding is not used in protocols, why does it
>appear in the MIB data formats?  It isn't adding any value; it
>certainly adds confusion.

We are getting off track here. The intent was that the IPOA-MIB use
a textual convention and appoarch for handling ATM Addresses with
that of the ATOMMIB. I will change IpoaAtmAddr to match what Kaj
posted in his last note:

 IpoaAtmAddr ::= TEXTUAL-CONVENTION
     DISPLAY-HINT "1x"
     STATUS  current
     DESCRIPTION
        "The ATM address used by the network entity.
         The semantics are implied by the length.
         The address types are:

         - no address (0 octets)
         - E.164 (8 octets)
         - NSAP (20 octets)

         In addition, when subaddresses are used the AtmAddr may
         represent the concatenation of address and subaddress. The
         associated address types are:

         - E.164, E.164 (16 octets)
         - E.164, NSAP (28 octets)
         - NSAP, NSAP (40 octets)

         Address lengths other than defined in this definition
         imply address types defined elsewhere.
         Note: The E.164 address is encoded in BCD format."
     SYNTAX   OCTET STRING (SIZE(0..40))

Along the same lines I've defined AtmConnKind locally within the
IPOA-MIB as IpoaAtmConnKind, changing ipoaVcType to use this TC,
and have added the following to the MIB module:

--  The following textual conventions are defined locally within
--  this MIB module. They have been prefixed with Ipoa to
--  distinguish them from their counterparts in the ATM-TC-MIB.
--  This was done so that the IPOA-MIB could be advanced as
--  a standards based MIB without waiting for the ATM-TC-MIB.
--  AtmConnKind, AtmAddr
--      FROM ATM-TC-MIB

The imports can be added in, comment deleted, and the local copies
deleted from the IPOA-MIB if the ATM-TC-MIB is approved by the IESG
prior to the IPOA-MIB.

Ken