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

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Mike Daniele writes:

Mike> Page 9
Mike> 
Mike>             The scope identifier may contain the special value 0
Mike>             which refers to the default scope. The default scope
Mike>             may be used in cases where e.g. a management application
Mike>             needs to write a site-local InetAddressIPv6 address
Mike>             without knowing the site identifier value.
Mike> 
Mike> I would change the last sentence to this
Mike> 
Mike> The default scope may be used in cases where the a valid
Mike> scope identifier is not known (e.g.,  a management application
Mike> needs to write a site-local InetAddressIPv6 address without
Mike> knowing the site identifier value).

I like these new wordings. I will use them in the updated version
unless there is an objection.

Mike> Page 11, sxn 4.2
Mike> 
Mike>    The InetAddressIPv6 textual convention has been defined to represent
Mike>    global and non-global IPv6 addresses. MIB designers who use
Mike>    InetAddressType/InetAddress pairs therefore do not need to worry
Mike>    about link-local or site-local addresses.
Mike> 
Mike> I'd change "worry about" to "define additional objects in order
Mike> to support".

Yes, reads much better. (Will use them unless I head an objection.)

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

Yes.

Mike> Page 11 sxn 4.4.
Mike> 
Mike>    DNS names must be resolved to IP addresses when communication with a
Mike>    host is required.
Mike> 
Mike> I'd change "a  host" to "the named host".

OK.

Mike> Page 11 sxn 4.4
Mike> 
Mike>    Similarly, the DESCRIPTION clause of such objects SHOULD precisely
Mike>    define how and when a reverse lookup is being done if an object is
Mike>    not created administratively.
Mike> 
Mike> This (and the peerAddress description)  assume that the agent
Mike> has accessed instrumentation that knows about an IP address,
Mike> and converted it to a DNS name.
Mike> 
Mike> This may not be the case.  (It may be quite unlikely in fact.  If you
Mike> have the address, use the address.)
Mike> 
Mike> So perhaps we should say that if the  MIB/implementation requires mapping
Mike> an address to a name,  information about reverese lookups should be
Mike> specified.

What about the following replacement for the quoted text above:

: Similarly, the DESCRIPTION clause of such objects SHOULD precisely
: define how and when a reverse lookup is being done if an agent has
: accessed instrumentation that knows about an IP address and the MIB or
: implementation requires to map the address to a name.

Mike> Page 13 at the bottom
Mike> 
Mike>   Note that the SMIv2 does not allow to list not-accessible objects in
Mike>    an object group (see section 3.1 in STD 58, RFC 2580 [8]).
Mike> 
Mike> Change "allow to list" to "permit inclusion of".

Yes, this reads much better.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>