IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 13 October 2016 15:01 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima-signaling@ietfa.amsl.com
Delivered-To: anima-signaling@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F00D129536 for <anima-signaling@ietfa.amsl.com>; Thu, 13 Oct 2016 08:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.897
X-Spam-Level:
X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNsmiJWhJbVe for <anima-signaling@ietfa.amsl.com>; Thu, 13 Oct 2016 08:01:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECCB12952A for <anima-signaling@ietf.org>; Thu, 13 Oct 2016 08:01:16 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E371820183; Thu, 13 Oct 2016 11:15:33 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8FDA26392C; Thu, 13 Oct 2016 11:01:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <34a6f1c3-9898-f1d8-70a9-60bfb59e21f2@gmail.com>
References: <12062.1476303921@obiwan.sandelman.ca> <34a6f1c3-9898-f1d8-70a9-60bfb59e21f2@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 13 Oct 2016 11:01:15 -0400
Message-ID: <6843.1476370875@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/U18EGbLgZebcazJ5jOYLL98s3Is>
Cc: anima-signaling@ietf.org
Subject: Re: [Anima-signaling] else clause in msg processing, or: where are the errors?
X-BeenThere: anima-signaling@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the signaling design team of the ANIMA WG <anima-signaling.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-signaling>, <mailto:anima-signaling-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-signaling/>
List-Post: <mailto:anima-signaling@ietf.org>
List-Help: <mailto:anima-signaling-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-signaling>, <mailto:anima-signaling-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2016 15:01:22 -0000

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.

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.

    > You are completely correct that this should be specified.

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

Do you have a preference?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email