Dario, I'm very sorry for taking so long to reply to your questions. >Document: >http://www.aciri.org/fenner/mibs/v6/draft-ops-rfc2011-update-00.txt > >Section 4 Page 7 >ipv6InterfaceEffectiveMtu: I assume the MTU is related to the whole >packet, and not just the payload, but I would like to make sure. Honestly, I'd rather just delete this object. It's from RFC 2465, and I don't know why it would ever be different than ifMtu of the underlying interface. >Section 4 Page 9 >ipv6InterfaceIdentifierLength: The reason for the existence of this >field should be clearly stated, e.g. in what case could we have an >interface identifier length different from 64 bits? >I suggest that we get rid of this object as it doesn't seem useful. This is another "inherited object" from RFC 2465 that I don't understand either. >Section 4 Page 16 >ipAddressPrefixEntry: The purpose of this object and the related >table is not clear. Assuming that we still wish to include it in >the new MIBs, please consider the comment below. The intent is to be able to determine the source of an IP address or a set of IP addresses. e.g., if you have a unicast and an anycast address configured for each prefix, having the prefix table allows not repeating the prefix information for each address but instead allows ipAddressPrefix to point to the row in the ipAddressPrefixTable that the prefix came from. >Section 4 Page 17 >ipAddressPrefixOrigin: Besides DHCP and router advertisements, >are there any plans to include other possible sources? >An example would be AAA: should we include this in "other(1)"? Can you give an example of assigning a prefix using AAA? >Could anyone provide another example of the wellknown origin for >IPv6 prefixes? The only available example is for IPv4 autoconfig. The Link-Local prefix is well-known for IPv6. >Section 4 Page 20 >ipAddressType: The lack of a multicast type should be clarified. >I suggest that we include multicast in this object: interfaces are >likely to have multicast addresses configured and we could include >them in the table, therefore creating the need for a multicast type. > >Section 4 Page 20 >ipAddressOrigin: The lack of an origin identifier for multicast >is unclear. Could anyone please elaborate on this issue? MLD handles multicast, including statically joined groups. e.g. RFC 3019's mldCacheSelf.ff.02.00.00.00.00.00.00.00.00.00.00.00.00.00.02.1 = True to join ff02::2 on interface 1. >Section 4 Page 22 >inetNetToMediaTable: I would like to make sure that our own >interfaces, besides Neighbor Discovery information, should be >included in this table. This seems to be the case. Yes, that's the intent, with inetNetToMediaType = local(5). >Document: >http://www.aciri.org/fenner/mibs/v6/draft-ops-rfc2096-update-00.txt > >Section 4 Page 4 >inetCidrRouteEntry: It is unclear why there is no scope information >in this object. It would be useful to include scope information in >this table, besides what is already available in ipv6ScopeIdTable. >I suggest that we include scopes in this object. The idea is that the inetCidrRouteInstance handle all reasons to have multiple routes with the same prefix, including scopes. The question is how to associate meanings with values of inetCidrRouteInstance, and we haven't answered that question yet. Bill -------------------------------------------------------------------- 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] --------------------------------------------------------------------
