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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 13 October 2016 19:43 UTC

To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <12062.1476303921@obiwan.sandelman.ca> <34a6f1c3-9898-f1d8-70a9-60bfb59e21f2@gmail.com> <6843.1476370875@obiwan.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <2e343772-296a-b885-0193-ff7186f4b055@gmail.com>
Date: Fri, 14 Oct 2016 08:43:41 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <6843.1476370875@obiwan.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/7cyMpLjisa7LFDHR3K99odbm5O8>
Cc: anima-signaling@ietf.org
Subject: Re: [Anima-signaling] else clause in msg processing, or: where are the errors?
Precedence: list

On 14/10/2016 04:01, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com> 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.
>     >>
>     >> 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'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.
> 
> 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.

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.

> 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.

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

> 
>     > 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.
> 
>     > You are completely correct that this should be specified.
> 
>     >> I would rather (3), including the errant session-id.
> 
> 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

[Anima-signaling] else clause in msg processing, … Michael Richardson
Re: [Anima-signaling] else clause in msg processi… Brian E Carpenter
Re: [Anima-signaling] else clause in msg processi… Michael Richardson
Re: [Anima-signaling] else clause in msg processi… Brian E Carpenter
Re: [Anima-signaling] else clause in msg processi… Michael Richardson