Re: [Cbor] GRASP packet header extensions (CBOR question)

[Toerless Eckert <[e-mail]>]

On Sat, Aug 20, 2022 at 10:01:37AM +1200, Brian E Carpenter wrote:
> Ditto, but referring to CDDL details. Off list, I suggested:
> 
>    grasp-option = numeric-option / objective
>    numeric-option = option .within option-structure
>    option-structure = [0..255, any]
> 
> and then
> 
>    option /= divert-option
> 
> etc.

I think this is a good starting point. Here is what i think is
possible/needed beyond that:

1) Breaks ttl

In rfc8990:

  grasp-option = any

If you constrain it to:

  grasp-option = numeric-option / objective

Then you break messages with ttl:

message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option]
flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]]

Aka: grasp-option can not represent the purely numeric ttl anymore.

We could do a one-off fix for ttl by channging message-structure, but
i really don't see why we would want to constrain grasp-option to be
less than any, see below.

2) Still want to understand .within correctly i think it does not doe
not work as you hope above.

Carsten claimed offlist, that in your above syntax, grasp-option would
match some option that is not yet defined, as long as it matches
option-structure. From reading rfc8610, i think this is wrong, because
numeric-option is an AND between option and option-structure, so only
any currently defined options will be matched. No extensibility to
include any future options, even if they match option-structure.

Of course, i can be wrong, but then rfc8610 text is really misleading.

3) Here is what i propose:

  
    grasp-option = valid-option / objective / any
    valid-option = option .within option-structure
    option-structure = [*any]
    option-type = uint


    flood-message = [M_FLOOD, session-id, initiator, ttl,
                    +[objective, (locator-option / [])], *grasp-option]

    "All other"-message = [ ... existing definitions ..., *grasp-option]


Explanations:

IMHO, we need to be able to introduce options that will be ignored when
an earlier GRASP implementation receives them. To do this, 
we must append *grasp-option to all message definitions. Else a
legacy receiver will not recognize the message as an existing message
according to the CDDL.

We already discussed that we want to be more flexible with option-structure,
hence the *any there.

The .within ONLY gives us a checker that all the options that
we define are matching option-structure. If we for example define

    option /= [ -1, "bla" ]

The name valid-option matches only those option that match option-structure,
but it does not match any structure that matches option-structure. So it
is IMHO not the solution for our extensibility problem.

Also: in any RFC valid-option must really be the same as option, because
otherwise we would have defined an option that doesn't match option-structure
(so it is an option, but not a valid-option), and of course we wouldn't want
to publish that as an RFC. But in any case, using valid-option in grasp-option
simply enforcesthat.

grasp-option must have any to allow extensibility with future options
as described above.

If someone wants to make the argument that we should not allow any,
then any needs to be replaced with option-structure, but not
removed. But i strongly suggest any. For example, we may want to add
maps later on as permitted structures. so why exclude them.

According to carsten, the "/" is match-first, so grap-option will
reliably match against any defined option and objective before it
goes to match any.

4) Breaking forward compatibility.

option-type should be defined by ranges. We can define that in CDDL
as well, just too lazy now:

standards-action, experimental

We may also want to carve out ranges to indicate that an option received
with such a numbe,if not known to the receiver must not be ignored but
needs to result in an error condition.

5) M_FLOOD

M_FLOOD still has the added issue, that it can have multiple objectives,
and we do not have a way to express per-objective options. Which bugs me.

Cheers
    Toerless