Re: FYI - 4 week IETF Last Call on endpoint MIB

[Mike Daniele <daniele@zk3.dec.com>]

hi,

just a few comments:

Page 9

            The scope identifier may contain the special value 0
            which refers to the default scope. The default scope
            may be used in cases where e.g. a management application
            needs to write a site-local InetAddressIPv6 address
            without knowing the site identifier value.

I would change the last sentence to this

The default scope may be used in cases where the a valid
scope identifier is not known (e.g.,  a management application
needs to write a site-local InetAddressIPv6 address without
knowing the site identifier value).

Page 11, sxn 4.2

   The InetAddressIPv6 textual convention has been defined to represent
   global and non-global IPv6 addresses. MIB designers who use
   InetAddressType/InetAddress pairs therefore do not need to worry
   about link-local or site-local addresses.

I'd change "worry about" to "define additional objects in order to support".

Page 11 sxn 4.3

   A single host system may be configured with multiple addresses (IPv4
   or IPv6), and possibly with multiple DNS names. Thus it is possible
   for a single host system to be represented by multiple (unique)
   InetAddressType/InetAddress pairs.

Remove "(unique)".

Page 11 sxn 4.4.

   DNS names must be resolved to IP addresses when communication with a
   host is required.

I'd change "a  host" to "the named host".

Page 11 sxn 4.4

   Similarly, the DESCRIPTION clause of such objects SHOULD precisely
   define how and when a reverse lookup is being done if an object is
   not created administratively.

This (and the peerAddress description)  assume that the agent
has accessed instrumentation that knows about an IP address,
and converted it to a DNS name.

This may not be the case.  (It may be quite unlikely in fact.  If you
have the address, use the address.)

So perhaps we should say that if the  MIB/implementation requires mapping
an address to a name,  information about reverese lookups should be
specified.

Page 13 at the bottom

  Note that the SMIv2 does not allow to list not-accessible objects in
   an object group (see section 3.1 in STD 58, RFC 2580 [8]).

Change "allow to list" to "permit inclusion of".

Thanks,
Mike