Thanks for your comments.
Comments/answers inline
> ----------
> From: Peder Chr. Nørgaard[SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 23, 2001 9:15 AM
> To: Wijnen, Bert (Bert)
> Cc: [EMAIL PROTECTED]
> Subject: Re: MLD MIB
>
> On Sun, 21 Jan 2001, Wijnen, Bert (Bert) wrote:
>
> > Date: Sun, 21 Jan 2001 23:38:56 +0100
> > From: "Wijnen, Bert (Bert)" <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: MLD MIB
> >
> > All,
> >
> > The MLD MIB is close to being published as RFC.
> > We found a few "editorial" changes that I am proposing to
> > the RFC-Editor. Just so you know. If you have a real
> > issue with it, then speak up very quickly. None of these
> > changes change anything in terms of bytes on the wire
> > or semantics.
>
> 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:
>From IPv6-TC module:
Ipv6IfIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero for each
internetwork-layer interface in the managed
system. It is recommended that values are assigned
contiguously starting from 1. The value for each
internetwork-layer interface must remain constant
at least from one re-initialization of the entity's
network management system to the next
re-initialization."
SYNTAX Integer32 (1..2147483647)
>From IF-MIB module:
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each interface or
interface sub-layer in the managed system. It is
recommended that values are assigned contiguously starting
from 1. The value for each interface sub-layer must remain
constant at least from one re-initialization of the entity's
network management system to the next re-initialization."
SYNTAX Integer32 (1..2147483647)
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.
> 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.
> 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.
Bert
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
