On Wed, 24 Jan 2001, Wijnen, Bert (Bert) wrote:
> >
> > I have to disagree with the premises of this statement, if not the
> > conclusion. This change does indeed change the semantics of the
> > implementation, and also the value of the bytes on the wire. The
> > InterfaceIndex and the Ipv6IfIndex are two different numbering schemes,
> Oh... are they?
> Then pls explain the difference between these two definitions:
Of course. I cut a bit to emphasize:
> Ipv6IfIndex ::= TEXTUAL-CONVENTION
:
> "A unique value, greater than zero for each
> internetwork-layer interface in the managed
^^^^^^^^^^^^^^^^^^ ^^^^^^^^^
> InterfaceIndex ::= TEXTUAL-CONVENTION
:
> "A unique value, greater than zero, for each interface or
^^^^^^^^^
> interface sub-layer in the managed system. It is
^^^^^^^^^^^^^^^^^^^
I read this as the difference between layer 3 only and all layers.
Certainly the InterfaceIndex covers all layers. And I find in the
IPV6-MIB a mapping from Ipv6InterfaceIndex to the InterfaceIndex - the MIB
object ipv6IfLowerLayer - that mapping is meaningless if the two values
are supposed to be identical! This forced me to interpret the two TCs as
representing two independent numbering schemes.
> They seem very much the same to me.
> And certainly, the data on the wire keeps to be an Integer32 with the
> same range!! The same is true for the other editorial changes.
Oh, yes, the *encoding* is identical. But if you - as I have done - has
implemented IPV6-MIB according to abovementioned interpretation - the
*values* are different.
> > and replacing the latter with the former forces changes in all
> > implementations. Cf discussion on the IPv6 Design Team homepage
> I do not see what needs to be changed in implementations.
>
> > <http://www.ibr.cs.tu-bs.de/ietf/ipv6mib-dt>.
> >
> That Design Team has been becoming active again, and they currently
> believe that it is best to get rid of Ipv6IfIndex. And they are looking at
> existing MIBs that use this TC to see what changes are needed. And
> they will soon submit I-Ds (I hope) to be discussed.
That would please me - if this is to be done, it must be done soon.
'Cause that change *will* force me to change implementation. (no big
deal, of course - actually a simplification.)
>
> > Unfortunately that discussion never reached a conclusion, so the MLD-MIB
> > designers do not really have any guidance in the choice between the two
> > schemes. Say, if the design team had concluded to do away with the
> > Ipv6IfIndex in the IPV6-MIB and friends, the MLD-MIB should of course do
> > the same.
> >
> > From my own position, the proposed change does not hurt, for I have not
> > completed the implementation of the MLD-MIB. But anyone with a working
> > implementation of MLD-MIB will have to modify code to adapt to this
> > change.
> >
> As I said I doubt they have to change much code (if any). All depends a bit
> on how an implementation was done. If anyone who implemented the MIB
> and who sees a big issue with this editorial change... pls scream.
Couldn't agree more. I'm not screaming. Just noticing :-)
--peder chr.
> Bert
>
--
Peder Chr. Nørgaard Senior System Developer, M. Sc.
Ericsson Telebit A/S tel: +45 89 38 52 53
Skanderborgvej 232 fax: +45 89 38 51 01
DK-8260 Viby J, Denmark mob: +45 21 28 66 58
e-mail: [EMAIL PROTECTED]
(old e-mail 1992-2000: [EMAIL PROTECTED])
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
