> > 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.
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. > 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. > > 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 [email protected] https://www.ietf.org/mailman/listinfo/anima
