Re: [Anima-signaling] Comments needed: issues in draft-ietf-anima-grasp-09

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 02 March 2017 14:15 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 BD138129577 for <anima-signaling@ietfa.amsl.com>; Thu, 2 Mar 2017 06:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 e8FX8n3u51iX for <anima-signaling@ietfa.amsl.com>; Thu, 2 Mar 2017 06:15:48 -0800 (PST)
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 2AC031294E9 for <anima-signaling@ietf.org>; Thu, 2 Mar 2017 06:15:48 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 957622009E for <anima-signaling@ietf.org>; Thu, 2 Mar 2017 09:38:08 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5CCF1636BB for <anima-signaling@ietf.org>; Thu, 2 Mar 2017 09:15:47 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Anima signaling DT <anima-signaling@ietf.org>
In-Reply-To: <eaec437b-db19-a0a5-3190-21b9a457d16d@gmail.com>
References: <eaec437b-db19-a0a5-3190-21b9a457d16d@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-sha256"; protocol="application/pgp-signature"
Date: Thu, 02 Mar 2017 09:15:47 -0500
Message-ID: <15000.1488464147@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-signaling/_-0MsGdMtSqlVOq9Xi9qOpVcUQE>
Subject: Re: [Anima-signaling] Comments needed: issues in draft-ietf-anima-grasp-09
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, 02 Mar 2017 14:15:49 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > - Split the document? [Charlie Perkins]

    > "parts of the document seem more philosophical than
    > prescriptive... It should be considered to break the document
    > into a Requirements document and a more rigorously defined
    > protocol solution document."

    > Proposed resolution: writing a separate requirements document
    > was essentially excluded when the WG was chartered. Unless the
    > WG and AD want to backtrack on that, the proposed resolution
    > is to *not* do this. Of course, all the specific review comments
    > about non-rigorous text will be actioned.

Mark the parts of the document which are requirements.
not having seperate documents doesn't mean that we can't be clear.

    > - Clarify security [Charlie Perkins]

    > "In some
    > places, ACP seems to be mandated, and in other places that is relaxed
    > to mean "a sufficient security mechanism".  It would be better to
    > identify the security requirements, and put them unmistakably in the
    > Security Considerations section, which deserves to have teeth."

    > (and various detailed comments in the text)

    > Of course we will deal with the detailed comments. The larger
    > issue is whether we should move most of the security discussion
    > to the Security Considerations section.

    > Proposed resolution: *Waiting for WG Chair and AD guidance.*

I think I already expressed my opinion:  "must be secured by ACP".
I would like no other exceptions or allusions to DTLS, etc.

    > - Text on circular dependencies [Joel Halpern]

...
    > Proposed resolution: We should be more explicit that this is a complex
    > issue that is simply not handled by the GRASP layer and that must be
    > considered by ASA designers.

+1

    > Proposed resolution: No change.

    > "3.8.13.  No Operation Message

    > In fragmentary CDDL, a No Operation message follows the pattern:

    > noop-message = [M_NOOP]

    > This message MAY be sent by an implementation that for practical
    > reasons needs to activate a socket.  It MUST be silently ignored by a
    > recipient.

    > CEP: ?? what does it mean to "activate" a socket?  Is there something
    > about
    > how long a socket may remain open but not used?"

    > Not that I know of. But I discovered that to find out the port number
    > assigned to a socket, you pretty much have to perform sendto() and
    > getsockname(), so the ability to send a no-op during initialisation
    > seemed reasonable. I could have just sent a zero, but a well-defined
    > message seemed better.

Also, we may need traffic to keep ACP links alive, or discovery that they are
in fact dead.  Or just for debugging.  It just seems useful to have to me.

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