Subject: [Anima-signaling] else clause in msg processing, or: where are the errors?

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Oct 2016 16:25:21 -0400

Looking at my rather minimal GRASP ASA implementation I wondered what I
should do with msg types I don't understand, or for that matter, with message
types that are not yet defined.

I don't see any clear statements in grasp-07 about error replies.
Maybe I missed it.

What does one do with an invalid msgtype?  Options are:
     1) ignore (drop msg)
     2) die: drop TCP connection
     3) reply with ???-M_INVALID or something.

I would rather (3), including the errant session-id.

I'm also a bit concerned that we have no statement about maximum message size.
As far as I can see, one can send [M_NOOP, 2^31-4ish bytestring, ...] and it
will be processed and ignored, eating bandwidth and CPU. I'd like to be able
to sanely allocate/limit space allocated for things.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Oct 2016 14:07:33 +1300

>      3) reply with ???-M_INVALID or something.

I'm not completely sure about this. Sending back an M_INVALID might
risk a loop condition. Silent ignore (or local diagnostic and ignore)
avoids that. I think that's what I coded. Certainly if we abort an
operation, I think we'll always drop the TCP session though.

Note that in a negotiotion session, we can in fact send
M_END with option O_DECLINE and an error string at any time.

You are completely correct that this should be specified.

> to sanely allocate/limit space allocated for things.

Well, specifically noop-message = [M_NOOP] so anything after the op-code
is illegal and can be dropped. But, yes, there is no defined limit on
an objective, so for example
flood-message = [M_FLOOD, session-id, initiator, ttl, (locator-option / []), +objective]
could be any length. But the other Michael wants to distribute Intent
of any length as a single lump. So what is a poor protocol designer
supposed to do? Should we leave it to the designer of individual objectives?

(Hmmm... this is a problem that a Python programmer can pretty much ignore,
since objects grow as desired.)

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Oct 2016 11:01:15 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> Looking at my rather minimal GRASP ASA implementation I wondered what
    >> I should do with msg types I don't understand, or for that matter,
    >> with message types that are not yet defined.
    >>
    >> What does one do with an invalid msgtype?  Options are: 1) ignore
    >> (drop msg) 2) die: drop TCP connection 3) reply with ???-M_INVALID or
    >> something.

    > operation, I think we'll always drop the TCP session though.

Clearly, M_INVALID has to be a MTI, and defined to say "ignore"
If we drop the TCP session without notice, then it's hard for us to introduce
new message types, as we can't probe to see if they are supported.

I notice that we have no protocol versions in GRASP: I'm not sure we need
them though, as for the ASA side of things, we ought to discover an ASA that
speaks the appropriate version.

    > Note that in a negotiotion session, we can in fact send M_END with
    > option O_DECLINE and an error string at any time.

Yes, I realized that we could do this for M_REQ_NEG.

    >> I would rather (3), including the errant session-id.

Do you have a preference?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Oct 2016 08:43:41 +1300

> new message types, as we can't probe to see if they are supported.

Well, we can detect the dropped session but we won't know the reason it was
dropped.

I can see exactly where I would handle it in my negotiation code: the line
where it says
    else:
        #if it isn't a valid message, ignore it

and, guess what, in the synchronization code:

    else:
        #if it isn't a valid synch message, ignore it

So it wouldn't be hard to add this from a practical viewpoint.

> speaks the appropriate version.

Yes, objectives have unique strings as names so versioning them is easy.

> Do you have a preference?

I'm still mulling it over. I will definitely put this on the issues list
for the end of WGLC. Sheng is concerned that we haven't had enough comment
on the WG list.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Oct 2016 09:58:52 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> I notice that we have no protocol versions in GRASP: I'm not sure we
    >> need them though, as for the ASA side of things, we ought to discover
    >> an ASA that speaks the appropriate version.

    >>
    >> > Note that in a negotiotion session, we can in fact send M_END with >

    > I'm still mulling it over. I will definitely put this on the issues
    > list for the end of WGLC. Sheng is concerned that we haven't had enough
    > comment on the WG list.

It's true, and this is one of the problems with design-team lists.

For the benefit of the WG list, my opinion is that we need two revisions of
grasp before it can advance.  I think that this can happen by the end of
November.

I'm happy if we want to publish at this point, knowing that we will revise
the document within a year, once we have a few more ASAs defined.
Otherwise, I feel that there are unknown issues that won't become known
(unknown unknowns..) until some ASAs do their thing.

I found using CBOR for the encoding make life REALLY REALLY easy.
(I used libcbor with C++ and cbor.gem with ruby).  Not, I only implemented
a very simple ASA.

I've done protocols in XML and the like, and even with sophisticated XML
library, it was never as easy as CBOR.