Subject: Re: ipNetToMediaPhysAddress

From: [email-masked]
Date: Wed, 19 Nov 97 11:31:01 EST

Paul,

>>> Also, what does "E.164 encoded in native format" mean?  The only
>>> native format I know of for E.164 is BCD encoding.  Is the 15-byte
>>> encoding supposed to be one digit per byte?  Bizarre.  If so, is
>>> that ascii digits or binary digits?  It has to be stated somewhere
>>> around here (since I don't think it's anywhere else).

>kennethw> E.164 encoded in native format means 15 octets in ASCII
>kennethw> format as oppose to a 8 octet BCD encoded one.

>Thanks.  I guess I won't use that format, especially since it doesn't
>show up in the protocols.  Where is this documented, by the way?  And
>for that matter, when is it expected to be used?  ("never" would be a
>good answer.)

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

>>> Sounds ok.  I guess we can push on the NetToMedia issue in the
>>> Atom MIB discussion rather than the Ipoa MIB discussion.

>kennethw> I don't think there is an issue with
>kennethw> ipNetToMediaPhysAddress. I've always thought that it was
>kennethw> implementation dependent as to its actual content. I will
>kennethw> add a clarifying comment on this in the IPOA-MIB.

>Huh?  What would be the reason for having it be implementation
>dependent?

How can it not? How would you define a standard object in the
ARP Cache, ipNetToMediaTable, that contains a physical address that
supports all physical address formats include the ones that don't
exist yet? Also, remember that the ipNetToMediaTable is part of
MIB-II and have been around for a considerable amount of time.

Ken