Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt

[Ben Maddison <[e-mail]>]

Hi Russ, Tim,

On 10/06, Russ Housley wrote:
> 
> <snip/>
> 
> This is just a matter of style I think.
> 
I've been thinking about this some more, and actually I think that this
choice *is* important when considering asn1 -> code compiler friendliness.

Consider:
    Foo ::= SEQUENCE {
        bar Bar,
        baz Baz,
        qux INTEGER
    }

    Bar ::= INTEGER

    Baz ::= INTEGER {
        a(0), b(1), c(2)
    }

Compiling this to (for the sake of example) rust would be expected to
produce something like:
    struct Foo {
        bar: Bar,
        baz: Baz,
        qux: usize,
    }

    struct Bar(usize);

    enum Baz {
        a = 0,
        b,
        c,
    }

Of course other language type systems have more-or-less direct
parallels.

Each has advantages and disadvantages:

-   the "qux" style can be used directly as an integer with no
    additional work, but you get no safeguards from the type system to
    prevent using a bare integer where you expected a "qux" value;

-   the "baz" style gives the type system the ability to distinguish Baz
    integers from other integers, at the expense of some extra work to
    define the operations on Baz types that are permitted; and

-   the "bar" style is not usable as an integer at all (at least not
    conveniently). The integer value is just there to distinguish the
    variants in memory.

I think this leads to the following general guidance:

1.  Use a bare INTEGER ("qux"-style) for unit-less, context-less integer
    values, that can be sensibly combined in an operation with any other
    integer value.
    This seems to be rare in practise to me, so should probably be
    limited to situations where simplicity is more important than
    correctness.

2.  Use a named type of type INTEGER ("bar"-style) for numbers that
    can be combined or compared with other numbers of a particular type.

    For example:
        bob.age != sue.age          # makes sense
        bob.height + sue.shoe_size  # probably a bug!

3.  Use enumerations ("baz"-style) when the *only* sensible operation
    that exists on the underlying numbers is equality comparison.

In the present case, I would suggest that the 'version' field falls
under category #2, since `foo.version < bar.version` could make sense in
some situations.

So, I would suggest:

    Manifest ::= SEQUENCE {
        version [0] Version DEFAULT 0,
        ...
    }
    Version ::= INTEGER

Note that this is orthogonal to whether we explicitly limit the
permitted value to 0, which can be done in any of the three schemes.
I have no particular view on whether that is a good idea or not.

Cheers,

Ben