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

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

>>>>> Brian Zill writes:

Brian> Conflicts: We already need to support the
Brian> <address>/<prefix-length> format for specifying prefixes.
Brian> Also, many things use conventions like <address>:<port> or
Brian> <address>@<port> which have already caused difficulties for
Brian> various reasons.  Putting the scope-id first avoids these
Brian> issues.

Why is [sid%]ipv6[/pfx][:port] simpler than ipv6[%sid][/pfx][:port]?
For me, the second version is simpler to parse since I always have the
ipv6 address in the first position and I only need to worry about
optional element at the end (which can all easily be identified by
looking at the delimiter).

Brian> Big-endian: Addresses are big-endian (most significant part
Brian> comes first).  The scope-id is more significant than the
Brian> address since it defines the area an address is meaningful in.
Brian> Putting the scope-id after would be like the American
Brian> Month/Day/Year convention with its mixed order instead of the
Brian> saner European Day/Month/Year convention which is pure
Brian> little-endian.

That is only true if the scope-id is indeed more significant. This may
in fact be true in many cases. But you can of course construct cases
where the American Month/Day/Year notation makes sense. ;-)

Brian> Aesthetics: Purely subjective.  Either you have taste, or you
Brian> don't :-)

Yep.

Brian> If I understand you correctly, the problem is that the
Brian> DISPLAY-HINT specifies the order of the bytes on the wire and
Brian> also does double-duty as a hint for how to display the value
Brian> textually (something to fix in SMIv3 I guess).  The former
Brian> usage I'm not concerned about, I'm only worried about the
Brian> latter.  (The order of the fields in a sockaddr_in6 doesn't
Brian> affect the textual representation, it's only the binary
Brian> representation - and it's also not an IETF standard.  The
Brian> reason the sin6_scope_id was put on the end was to allow for
Brian> backwards binary compatibility with earlier incarnations of
Brian> sockaddr_in6.)

The DISPLAY-HINT does not define the wire representation. The wire
representation is only defined in the DESCRIPTION clause. However,
this gets more complicated if the position of the IPv6 addresses is in
the first 16 bytes for global addresses and in the last 16 bytes for
non-global addresses. I am sure that this will lead to implementation
errors and thus interoperability problems. Having the IPv6 always in
the first 16 bytes on the wire avoids this.

The DISPLAY-HINT clause comes into play in when it comes to define a
conversion into something human readable. And the SMIv2 we have only
allows to have optional parts at the end, not at the beginning.
Putting the scope identifier in the first bytes means that we can't
define a reasonable machine readable DISPLAY-HINT. Programs that
interpret DISPLAY-HINTs will thus just render things in whatever the
default for binary data is.

Brian> I don't know enough about this to recommend a work-around.  Is
Brian> it possible to add a notation stating that for this definition,
Brian> only the wire representation meaning is intended to apply and
Brian> that one should read the eventual ipngwg draft on this for the
Brian> textual representation?

I would certainly prefer that the IPng WG decides on a format which
puts the optional part at the end to avoid the problems outlined
above.

/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/>