Subject: [Anima-signaling] CDDL mistake

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Dec 2016 11:43:17 +1300

Hi,

I've just realised that I have a mistake in my GRASP code
concerning the following CDDL:

objective-flags = uint .bits objective-flag
objective-flag = &(
 F_DISC: 0 ; valid for discovery only
 F_NEG: 1 ; valid for discovery and negotiation
 F_SYNCH: 2 ; valid for discovery and synchronization
)

What I've actually implemented is this:

objective-flags = &(
 F_DISC: 0 ; valid for discovery only
 F_NEG: 1 ; valid for discovery and negotiation
 F_SYNCH: 2 ; valid for discovery and synchronization
)

On balance I think this is better (and certainly easier to implement).
There doesn't seem to be any advantage in using bit positions.

Any feedback?

     Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Dec 2016 18:07:53 -0500

> concerning the following CDDL:

So, basically, you are replacing a set with an enum.
I don't see a problem for the current three flags.

    > There doesn't seem to be any advantage in using bit positions.

What happens if we need an additional flag?
Bit positions had the advantage that you understand the things you understand
and ignore the rest.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Dec 2016 15:09:36 +1300

> Bit positions had the advantage that you understand the things you understand

I noticed the problem while adding code for the (proposed) new F_NEG_DRY flag,
and doing so in a language where uints are easier to deal with than bits.
But ignoring (or throwing an error) for unknown flags doesn't seem hard in
either case.

At the moment it's an error in my code which I can fix in a few minutes.
I'm happy to do so, and leave the CDDL unchanged. I really don't have strong
feelings, just want input.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Dec 2016 10:56:21 -0500

> I noticed the problem while adding code for the (proposed) new

I think upon reflection, that I'd rather the bit definition.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Dec 2016 08:02:19 +1300

> I think upon reflection, that I'd rather the bit definition.

Yes, I was mulling it over and I reached the same conclusion. I think I
need to to tweak the text a bit to avoid other implementers making the same
mistake that I did. Thus:

<section title="Objective flags">

<t>An objective may be relevant for discovery only, for discovery and negotiation, or
for discovery and synchronization. This is expressed in the objective by logical flags:</t>
<t><figure>
<artwork><![CDATA[
  objective-flags = uint .bits objective-flag
  objective-flag = &(
  F_DISC: 0    ; valid for discovery
  F_NEG: 1     ; valid for negotiation
  F_SYNCH: 2   ; valid for synchronization
  F_NEG_DRY: 3 ; negotiation is dry-run
  )
  ]]></artwork>
</figure></t>
<t>Note that for a given negotiation session, an objective must be either used for negotiation, or for
dry-run negotiation. Mixing the two modes in a single negotiation is not possible.</t>
</section>

Does this work?

Now I will mend my Python code.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Dec 2016 13:31:25 -0500

> Does this work?

So either bit 1 is set, or bit 3 is set?
Rather than bit 1 is set for a real negotiation, and bits 1 and 3 are set
for a dry-run?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Dec 2016 11:44:22 +1300

> Rather than bit 1 is set for a real negotiation, and bits 1 and 3 are set

OK, I can see that we need to disambiguate the text a bit more (this can't
as far as I know be expressed in CDDL). I think I'd vote for or'ing the bits,
so that if we later found a case of an objective that could be either
synched or negotiated, we could set both bits. So in that case, for a
discoverable negotiable objective and a dry-run, we'd set F_DISC and F_NEG
and F_DRY, ending up with 0x0B.

    Brian