Re: Problem with draft-ops-endpoint-mib-05.txt

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

Hi Brian,

Brian Zill wrote:

<...>

> [Combining the two messages...]
> > The DISPLAY-HINT goes works with the ordering of the
> > bytes in on the wire. We need 16 or 20 bytes to represent
> > global and non-global addresses. The only reasonable way
> > in the current SMIv2 is to have the optional bytes at the
> > end. Sure, you can call the current SMIv2 (STD 58) broken.
> > But that won't help to solve the problem since it is a
> > standard. (BTW, even the struct sockaddr_in6 puts the
> > sin6_scope_id field "behind" the sin6_addr field.)
>
> If I understand you correctly, the problem is that the DISPLAY-HINT
> specifies the order of the bytes on the wire and also does double-duty as a
> hint for how to display the value textually (something to fix in SMIv3 I
> guess).

DISPLAY-HINT does not specify the ordering of bytes on the wire.
It is simply a suggested default mechanism for applications that have no
knowledge of what they are displaying, to display those bytes.  And it's
contrained to use the specified ordering.

The DISPLAY-HINT (or lack thereof) does not imply what knowledgeable
applications should do.  For example, the MIB variable sysUpTime has syntax
TimeTicks (really INTEGER), and no DSIPLAY-HINT at all:

          sysUpTime OBJECT-TYPE
              SYNTAX  TimeTicks
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The time (in hundredths of a second) since the
                      network management portion of the system was last
                      re-initialized."
              ::= { system 3 }

Yet it is almost universally displayed in Days-Hours-Minutes type of formats
by SNMP applications.


>  The former usage I'm not concerned about, I'm only worried about
> the latter.

And we appreciate your efforts.  Hopefully we can conclude this thread now.


>  (The order of the fields in a sockaddr_in6 doesn't affect the
> textual representation, it's only the binary representation - and it's also
> not an IETF standard.  The reason the sin6_scope_id was put on the end was
> to allow for backwards binary compatibility with earlier incarnations of
> sockaddr_in6.)
>
> I don't know enough about this to recommend a work-around.  Is it possible
> to add a notation stating that for this definition, only the wire
> representation meaning is intended to apply and that one should read the
> eventual ipngwg draft on this for the textual representation?
>

I think it would be ok to add some text saying that there is likely to be
IPv6 or IPng specs that suggest a presentation format.

Would that end the presentation format/DISPLAY_HINT issue?

Thanks,
Mike