On 23-Aug-22 06:43, Carsten Bormann wrote:
Aka: grasp-option can not represent the purely numeric ttl anymore.
That's actually a bug in the changes I was proposing. It will be
fixed but I doubt that the cbor list cares.
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.
Correct.
Grasp-option really is the lower layer of extensibility, which allows you to
create new messages that then conform to message-structure. These should
provide maximum flexibility.
(Message should be/employ a socket, to make this extension point more visible.)
The production that is called grasp-option should not be called grasp-option,
because it is not just about options, it’s all elements in a message after the
common header.
Correct. Will fix.
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.
So each message production should have a *grasp-really-option at the end, where
that stands for an actual (registered) option.
I don't really see that. But let's have that argument about a complete
updated CDDL spec, and not waste cbor@'s time.
Brian
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]
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.
[…]
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…)
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…
Grüße, Carsten
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
