On 23-Aug-22 22:35, Toerless Eckert wrote:
On Mon, Aug 22, 2022 at 08:43:57PM +0200, Carsten Bormann wrote:
[... snip...]
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.
I’m not sure I understand the context of this, but yes, .within is a .and. So
you have to have both message-structure accept the message and the message
choice as well.
Obviously, we need a second layer of extensibility beyond adding new messages:
adding new options to a message.
I think we've got that covered in our understanding.
Except that for me this will be a rare event since it requires
updates to the core part of GRASP, and should be avoided
unless essential.
So each message production should have a *grasp-really-option at the end, where
that stands for an actual (registered) option.
But that would not suffice to receive and ignore an option that
was not specified in the CDDL at the time of the implementation of the
receiver.
No, because *in any case* that is done by the programmer who writes
the decoder. The programmer needs text instructions; the CDDL cannot
provide those instructions.
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
(Valid-option is your grasp-really-option.)
option-structure = [*any]
No, an option starts with an option-type, so this should be
option-structure = [option-type, *any]
Oops. typo. Thanks
option-type = uint
Yep.
flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])], *grasp-option]
Yes.
"All other"-message = [ ... existing definitions ..., *grasp-option]
Yes, that would be the whole-sale introduction of the second layer.
(Grasp-really-option, actually.)
The [~message, *grasp-really-option] approach might be able to do this with
fewer changes.
Hah. "~" is the unravel i was asking for in my other mail. Can that be
used to do inline moficiation:
flood-message = [ ~flood-message, *grasp-option ]
Or does that have to be a new name on the left-hand side ?
[…]
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.
(Negative numbers would lend themselves to this…)
Right...
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.
… a fourth layer of extensibility…
Yeah. Still trying to find the killer use-case of two objectives requring
different
options to make that point.
My opinion today is that it was a mistake to allow multiple objectives in one
flood message. We should have stuck to a KISS approach.
Brian
Thanks
Toerless
Grüße, Carsten
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
