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
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
