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

[Brian E Carpenter <[e-mail]>]

Just a couple of comments in line:

On 22-Aug-22 21:09, Toerless Eckert wrote:
> 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.

I think that correct use of .within covers that point, if a protocol
decoder is adhering to CDDL in some strict fashion. If it isn't
CDDL-driven, which is the norm, the text in RFC8990 already tells
it to ignore unknowns.

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

It turns out that we need any in the .within structure anyway,
to make the CDDL consistent with all the existing messages.

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

I'm against that. IMHO we should limit complexity and change in the core
part of GRASP, and use the infinite flexibility already allowed
in objective definitions.
  
> 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.

It doesn't bug me, because I see all the expressivity we need
in objective-value = any.

    Brian
> 
> Cheers
>      Toerless