Bill,
Here are 36 items on draft-ops-rfc2011-update-00.txt
Regards,
Mike
1. This MIB module has read-write objects,
please define the persistence of a set operation for
ipForward, ipDefaultTTL, etc.
See section 3.1.12 of draft-ietf-snmpconf-bcp-04.txt
2. There is no support for multi-stack/same Address Family
implementations. Please consider support and if
not, then please state reasoning in front matter.
See section 3.1.20 of draft-ietf-snmpconf-bcp-04.txt
3. I suggest liberal use of REFERENCE clause
for objects that represent fields exactly as defined
in an underlying protocol specification.
For example ipv6DefaultHopLimit
as specified in 2460 sec 3, 8.2). For a well
developed example, see RFC 2674.
http://www.nanog.org/mtg-0102/ppt/mibs/sld010.htm
4. ipv6Forwarding: The DESCRIPTION is not appropriate.
An agent caps document would define the implementation
limitations.
The recommendation as to what to return 'wrongValue' is
protocol specific. A future version of the SNMP
may prefer a different way to indicate the lack of
a capability.
"Note that for some managed nodes, this object may take on
only a subset of the values possible. Accordingly, it is
appropriate for an agent to return a `wrongValue' response
if a management station attempts to change this object to an
inappropriate value."
5. "what about SIIT object saying whether an IPv4 address?
describe SIIT mapped or natively mapped on a dual-stack system?"
Based on this statement in rfc2765, section 1:
"Note that SIIT is not likely to be useful later during transition
when most of the Internet is IPv6 and there are only small islands of
IPv4 nodes,..."
I suggest any such objects be placed in a new SIIT MIB module and
not defined here.
6. Please define an explicit object(s) to express capability of an
implementation. See the object dot1dDeviceCapabilities
as defined in rfc 2674.
Section 4 of rfc 2460 provides the list
of extension headers, it is probably that some implementations
may not implement all features or if future extensions headers
are added, it will be useful to identify what a given implementation
supports. For IPv6, it might includes handling of
various headers, flow label, traffic class, ..
7. I like the ipv4IfTable as it makes more sense to organize
some IP attributes by ifIndex. You might also consider the following:
- directed broadcast (T/F)
- proxy-arp (T/F)
- tcp header compression (T/F)
- broadcast address --> ipAddressv4BcastAddr
- arp cache timeout (NUM/UNIT secs)
For an example of existing IPv4 implementation that allows per
interface configuration, see ip sub-interface CLI command on a
Cisco IOS(tm).
8. General request: Please add *LastChange and *Number objects
for all tables to allow mgmt apps to maintain caches.
9. ipv6InterfaceTable -
ipv6InterfaceEffectiveMtu - like you said, can be easily computed.
ipv6InterfaceReasmMaxSize - my experience is this is not per interface.
"ipv6InterfaceAdminStatus: does it make sense to enable/disable
IPv6 on its own on the interface?"
One will want to enable/disable a given Address Family on a
interface shared by multiple address families.
I've seen implemented systems where there are entries
in the ifTable for IP Interfaces that provide the functionality.
I'd prefer a single table to enable/disable an
IP Interface(struct ifnet) as opposed to a port.
See: http://www.nanog.org/mtg-0102/ppt/mibs/sld051.htm
"ipv6InterfaceOperStatus: other than the above, noIfIdentifier(3)
is this one's only useful state, which can be determined from
the Address table if DAD failed or there is no v6 address on
this interface. [not efficiently, though]"
I prefer we have an OperStatus if an admin status is included.
It would be useful even in IPv4 to see what else might fail such
as dhcp assigned addresses or in a particular implementation
some lack of resources, etc.
ipv6InterfaceIdentifier Ipv6AddressIfIdentifier,
ipv6InterfaceIdentifierLength INTEGER,
ipv6InterfacePhysicalAddress PhysAddress
I suggest the compliance section state it is acceptable
that MIN-ACCESS be read only.
Most interfaces for will compute these
and even for interfaces which may not be straight forward
like serial, the current drafts stil provide a way to
have an implementation generate acceptable values.
"When can this be different from the address of the
interface's protocol sub-layer, and why?""
I am aware of at least one IP router
that ships with a cache of operator assignable
IEEE MAC addresses to provide to user define
IP interface.
All physical ports in the system have one hardwired MAC, hence
the ifPhysAddr of the port != ipNetToMediaPhysAddress
of the given IP Address.
10. ipIfStatsTable -
"A row with an ipIfStatsIfIndex value of zero indicates a
system-wide value; a row with a non-zero ipIfStatsIfIndex"
Using 0 in an index is not recommended. Please see
section 3.1.7 of draft-ietf-snmpconf-bcp-04.txt.
11. ipIfStatsTable counters -
Most of these counters are so weakly defined such that
two implementations may not count the same thing.
Please fix these counters so they are derived from
the underlying protocol specs.
Then use a REFERENCE clause in the MIB module to link
to the value (See RFC 1493 for example).
This will help ensure two different implementations have
some verifiable consistency for these counters.
Also, these counters are subject to discontinuity.
For all counters, please specify which discontinuity
object to use. Some background info here:
http://www.nanog.org/mtg-0102/ppt/mibs/sld030.htm
12. Since ipIfStatsInTooBigErrors is only valid for IPv6,
please state what to do for IPv4 in compliance stmts
such that this object may or may not exist.
13. I started to wonder if ipIfStatsTable will need
two separate counter sets by address family. Then I
realized it isn't necessary as rfc2011/1213 are not
going to go disappear from any new implementation
any time soon.
14. ipIfStatsTable counters - refresh rate
different implementations often have different
refresh rates for snmp counters.
It might be useful to have an read-only
object to express the implementations
refersh rate on such counter
in milliseconds to minutes. See
http://www.nanog.org/mtg-0102/ppt/mibs/sld036.htm
15. Internet Address Prefix table -
I suggest ipAddressPrefixOrigin enum be a TC
Also suggest "wellknown" be better defined as to what
document defines the well known addresses (iana?)
16. I can't see how ipAddressPrefixTable is useful for IPv4.
Why can't this jut remaing an ipv6 table with references
to rfc2461/draft-ietf-ipngwg-site-prefixes-05.txt
ipAddressPrefixOnLinkFlag
ipAddressPrefixAutonomousFlag
ipAddressPrefixAdvPreferredLifetime
ipAddressPrefixAdvValidLifetime
17. ipAddressIfIndex description should
just refer to IF-MIB and not rfc2863.
18. ipAddressType, maybe reiterate that broadcast
isn't valid option for IPv6 w/reference to
draft-ietf-ipngwg-addr-arch-v3-05.txt
19. ipAddressPrefix value "0.0" is good.
20. ipAddressOrigin should be a TC (see item 15)
I prefer dhcp (v6 or v6 if need be) over some
general string such as "assignedByServer" anyone
using bootp?
I don't know what is "random" -
how does this differ from manual?
21. There should be an object ipAddressOriginCreationTime
which is the sysUpTime when the assignment
was made.
22. ipAddressStatus should be a TC if it needs to exist at all.
I am not sure how useful all these states are and if
two implementations will even come close in terms
of using them the same way.
a) If I assign an interface to a port,
it goes preferred, then I
delete the assignment, the state goes either to
deprecated and at some time, the row is aged out
or the row simply will fail to exist.
b) The inaccessible(4) value is unnecessary. It is simple
to scan the ifTable corresponding to ipAddressIfIndex
and determine state.
c) I doubt invalid(3) would ever be used.
d) duplicate() - this is interesting idea, but
not sure how useful it is and at what time the status
of this object would transfer out of duplicate state
once entered.
e) is tentative only applicable to IPv6?
23. If ipAddressStatus survives the next edit,
it needs the equivalent of ifLastChanged.
24. inetNetToMediaTable -
might want to reference ARP protocol specifications.
25. inetNetToMediaType -
Adding 'local' value is redundant. It provides
no addtional value I can see.
'static' works just fine for this case.
26. "inetNetToMediaState - why no value for incomplete?"
I agree it would be useful to add text to
a) describe if these should be in the table
b) if so how to represent it (ie use 0 for PhysAddress).
The past implementations I'm familar with
have not listed unresolved entries.
I think a separate table might exist for these though
along with some stats/counts/high-watermarks, etc.
Table description should state what it expects.
27. "inetNetToMediaState - what values for !ipv6? noNUD(7) or unknown(6)?"
The description states use unknown(6) which is fine by me.
If Neighbor Unreachability Detection is not in use (e.g. for
IPv4), this object is always unknown(6) XXX ?noNUD(8)?."
28. ScopeIdentifier - remove reference to rfc2233 in description.
29. "Should there be associated objects to provide a scope description,
similar to ipMRouteScopeNameString?"
I don't think so.
I can see that it might be useful for diagostics, but I don't
think the admin overhead of setting it up is reasonable?
30. inetIcmpTable - Use of value 0 is not recommended. see
item #10 above.
31. The summary counters might not be all that useful in the
form presented. Especially if the number
interfaces are large in a given network element.
As an alternative to a summary, maybe provide
a "top N" style view of icmp errors by interface
to answer the question, which interfaces have the
most errors?
32. inetIcmpTable should reference underlying spec for counters.
See item #11 above.
33. inetIcmpMsgTable - same indexing problems as #30
inetIcmpMsgEntry, if you remove the summary indexing
the table's values make implementation more likely
to be correct. I don't see what the summary really
buys anyway when getting such detailed information.
I think this table should be optional on a per
interface basis too.
34. inetIcmpMsgTable - special value 256.
A different implementation would simply provide the
counts in some scalars of the "others" category. Current
model seems needlessly convoluted.
35. inetIcmpMsgTable - it may be that operators only want
to see certain icmp messages and not all?
36. inetIcmpMsgType - should be a TC and include a reference
to underlying spec.
Other MIB modules should able to use the same definition.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
