Subject: [Anima-signaling] Two definite proposals for GRASP protocol change

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Dec 2015 17:00:10 +1300

1)

I invented the PEN field so I think I can also kill it. My proposal is that we take
this out of the protocol itself. We state that an objective's name is ":whatever" if
it's generic and "vendorString:whatever" if it's vendor specific. The formal
definition of vendorString is that it's a unique UTF-8 string not including ":".
The format MAY be an FQDN, an email address, or a PEN (represented as a decimal
number).

As far as GRASP is concerned, an objective name is now simply a string.
Simpler protocol, simpler code.

2)

Add a global IP address in all Discovery and Response messages, which is
a valid address for the initiator, to avoid the remote chance of clashing
session IDs. There isn't much run time cost since it only needs to be
tested when the IDs clash. It isn't necessary for the other messages,
which are always unicast so local and remote session IDs can be distinguished
anyway.

If I hear no objections I will add these changes to the text tomorrow.

I'm happy. My Python code for GRASP discovery is beginning to work.
This doesn't look much, but it's telling me there is something in the
discovery cache:

>>> discovery_cache[0].asa_locators[0].locator
    IPv6Address('2406:e007:6917:1:28cc:dc4c:9703:6781')
>>> discovery_cache[0].objective.name
    ':Boot'
>>> discovery_cache[0].objective.disc
    True

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Dec 2015 15:21:43 +0100

> The format MAY be an FQDN, an email address, or a PEN (represented as a decimal

With the last sentence, there is some hope of uniqueness.

(Of course, we have about a million ways of doing this already in the
IETF; URNs etc., but the above selection sounds good.)

There is no need for the initial : if you stipulate that generic
(registered) objectives cannot contain a :.

> Simpler protocol, simpler code.

Sounds good.

> session IDs. 

1) I may not have a global address yet at the time I build such a
message, right?

2) Because people will start using these fields for all kinds of things
(starting side conversations etc.), I'd rather be careful about adding
mechanism that implies some semantics (here: that of an IP address).

Better to mix in more of this information into a session ID (which needs
to be long enough to make clashes after a reboot unlikely).

>>>> discovery_cache[0].objective.disc

Nice!

One thing I'd like to see is extractable CDDL.

1) Right now, I can't use the usual XPath expression

   //artwork[@type='CDDL']/text()

because the artwork elements don't have type attributes.

2) The "fragmentary CDDL" concept does not work if the extracted CDDL is
to be useful to run checks over it etc.  So, I'd change constructs of
the form

     option /=      ; one of the options defined below

into

     ; use
     ;    option /= ...
     ; to define choices for the options.

(BTW, please have a look at

https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-07#appendix-B.1.5

for a way to combine a general format with specific choices.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Dec 2015 15:50:05 +0100

... and looking at the CDDL after extracting it manually:

MESSAGE_TYPE is what kind of thing?

Assuming this might need to extensible, I think specifying something like

MESSAGE_TYPE = 0..255 ; a constant defined below

might help (alternatively: 0..99, if you want to keep them separate from
option numbers).

MESSAGE_TYPE = M_DISCOVERY / M_RESPONSE / M_REQUEST / M_NEGOTIATE /
M_END / M_WAIT

(We might also define `option` and `OPTION_TYPE`, where the former
includes the ip locator options as well as the options built from type
numbers.)

s/tstr/text/g, I'd say.

What does it mean to use the same objective-name with different
objective-flags?

Grüße, Carsten

Carsten Bormann wrote:
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Dec 2015 09:05:08 +1300

> (registered) objectives cannot contain a :.

Yes, correct, thanks!

> 1) I may not have a global address yet at the time I build such a

Hmmm... that's true, there can be cases where the node only has a
a link local address (or worse, an RFC1918 address). I need to
think a bit more.

> to be long enough to make clashes after a reboot unlikely).

Good point. But I'd rather avoid a birthday-paradox risk of collision
completely.

    Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Dec 2015 09:11:05 +1300

> might help (alternatively: 0..99, if you want to keep them separate from

Yes, thanks.

> includes the ip locator options as well as the options built from type

Might be cleaner.

> s/tstr/text/g, I'd say.

Yes

> What does it mean to use the same objective-name with different

You use D when only conducting discovery, and N or S when also
conducting negotiation or synchronization respectively. It's possible
these flags are not really needed - to be frank I will know that when
I have completed coding my prototype. If I never need to test the flags
they can be removed.

Regards
   Brian