[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    RE: MLD MIB
From:       "Wijnen, Bert (Bert)" <bwijnen () lucent ! com>
Date:       2001-01-26 11:39:29
[Download RAW message or body]

Comments inline

> ----------
> From: 	Peder Chr. Nørgaard[SMTP:Peder.C.Norgaard@ted.ericsson.dk]
> Sent: 	Wednesday, January 24, 2001 9:51 PM
> To: 	Wijnen, Bert (Bert)
> Cc: 	Peder Chr. Nørgaard; ipng@sunroof.eng.sun.com
> Subject: 	RE: MLD MIB
> 
> 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.
> 
Mmm... maybe... but I wonder if that was intentional.
Anyway... the ipv6mib design team is looking at these MIBs and
they will come up with proposed new (clariying text).

> > 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.)
> 
Good to hear it is a simplification in yoru eyes.
The DT is working hard on the MIBs. I hope to see I-Ds pretty soon now.

> >
> > > 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 :-)
> 
Good. So I went ahead and asked RFC-Editor to make those "editorial changes"

Bert

> 				--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: Peder.C.Norgaard@ted.ericsson.dk
>          (old e-mail 1992-2000: pcn@tbit.dk)
> 
> 

--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]