Re: [DNSOP] draft-ietf-dnsop-session-signal: session establishment

Stuart Cheshire <cheshire@apple.com> Mon, 29 January 2018 19:38 UTC

Return-Path: <cheshire@apple.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70457131897 for <dnsop@ietfa.amsl.com>; Mon, 29 Jan 2018 11:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 Mq0Ie-tDp-Ww for <dnsop@ietfa.amsl.com>; Mon, 29 Jan 2018 11:38:20 -0800 (PST)
Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D4B12EA9D for <dnsop@ietf.org>; Mon, 29 Jan 2018 11:38:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1517254699; x=2381168299; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=43jNEKmc4xAI08wb0AIsdfpW38jMTeeULRoM3yBs/ls=; b=U93h3zdv+rH+LXr8WLbai2k6qokyyWjfpGGG3YDfoyu9JTsG/bLTVLKyKsqrvMXR s4JBF3tXKE8UvtcRUlsTnRy5ALn8rCktU4in94vNqcbrZtq43PVovs0FT6elBBWM uJVvlKjPIM5fiX2ridPFj9/RsxcAWe3EPpqcD7/xR/JjSjjrtvu6OS61wR0VlJ1f atK+DOfGzH1pGVSsMFcp6WAEyfcQbO3QfbjZODjexlpoObMgwCcvY543UAE1ErCj /3g5xQ3Up+a/il4y3V39jyDmr/mjbgT+1xX21EztlaV+DmToc4g94tPhWF1C5ZB2 CnYrsIrdHfqxms27mzaD+Q==;
Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 8B.72.14365.A287F6A5; Mon, 29 Jan 2018 11:38:19 -0800 (PST)
X-AuditID: 11ab0219-e904d9e00000381d-0e-5a6f782aaae5
Received: from kencur.apple.com (kencur.apple.com [17.151.62.38]) by relay3.apple.com (Apple SCV relay) with SMTP id 83.DD.12852.A287F6A5; Mon, 29 Jan 2018 11:38:18 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [17.226.23.47] (unknown [17.226.23.47]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.2.1.20171204 64bit (built Dec 4 2017)) with ESMTPSA id <0P3C00HQN17TWE50@kencur.apple.com>; Mon, 29 Jan 2018 11:38:18 -0800 (PST)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <C59E9AA2-10FA-451C-BBCA-FB380C6D8C99@vpnc.org>
Date: Mon, 29 Jan 2018 11:38:15 -0800
Cc: dnsop <dnsop@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <A85143F5-7CE1-442C-877E-949F55488036@apple.com>
References: <C59E9AA2-10FA-451C-BBCA-FB380C6D8C99@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3445.5.20)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FAYrKtdkR9lcCjO4u6byywWt9Z/YXVg 8liy5CeTx+fZV5kDmKK4bFJSczLLUov07RK4Ml4vusde8Je/4t3Sw8wNjJ94uhg5OSQETCSW bDnL1MXIxSEksIZJ4v2zG4wwiYs/WpghEpsYJT5NusgMkuAVEJT4MfkeSxcjBwezgLrElCm5 EDWNTBILpjexgtQIC0hJvFr5mRnC9pb4+XA+2FA2AS2JF5+vsIHYnAI2EnN2LAWrZxFQlfg2 cRtYnBmod9KUeawQtrbEk3cXWCH22kjc3t8KNkdIwFpiencnE4gtIqAhceHhDnaIo5Ukpn+/ zQZykIRAI5vEhi3P2ScwCs9CcvcshLtnIVmxgJF5FaNwbmJmjm5mnpGpXmJBQU6qXnJ+7iZG UGivZpLcwfj1teEhRgEORiUe3huK+VFCrIllxZW5hxilOViUxHkjlbOihATSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTAW+lScPcmnZeN0cG3aj7LaIzyBIc4h0xbOmVSgc2+HZoZycuUp11uZ V27Ef1VjfM/Sx7tti8UHkfQzu6LFecoOrDvymu/7NMXg+JVfnBecnLLz/j+jD/MkuXwZ2Dbx Xr/Q/ODy8bZja2eVbQy/zR1+/+7vhPPvH9fo7NA2mO3ncXXOzTtFMkGmSizFGYmGWsxFxYkA DtLLME4CAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUiON1OTVerIj/KYMM2GYu7by6zWNxa/4XV gcljyZKfTB6fZ19lDmCK4rJJSc3JLEst0rdL4Mp4vegee8Ff/op3Sw8zNzB+4uli5OSQEDCR uPijhbmLkYtDSGATo8SnSReZQRK8AoISPybfY+li5OBgFlCXmDIlF6KmkUliwfQmVpAaYQEp iVcrPzND2N4SPx/OZwSx2QS0JF58vsIGYnMK2EjM2bEUrJ5FQFXi28RtYHFmoN5JU+axQtja Ek/eXWCF2GsjcXt/K9gcIQFriendnUwgtoiAhsSFhzvYIY5Wkpj+/TbbBEaBWUhOnYVw6iwk UxcwMq9iFChKzUmsNNZLLCjISdVLzs/dxAgKxYbC4B2Mf5ZZHWIU4GBU4uE1UMmPEmJNLCuu zD3EKMHBrCTCe68wL0qINyWxsiq1KD++qDQntfgQozQHi5I470ue3CghgfTEktTs1NSC1CKY LBMHp1QDI0uzb1/iGf7dSr6Fdy3XKEuZBs6rDb16huW28qpdMXsWWZ3iK/aqrnBqUoj/p8b7 wGBb59byQvcf+6fP/uAttMz4tdV9TkkV9k1vEz+7ClUmTvR0OT3P/eN8tg+x0p828bIzNYcK fXI5J7jiQ0yARrH7RJbZWxb83PFl+9JLmX2pz8PWNmp7KrEUZyQaajEXFScCAN1iB9NBAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KZ57qufO0lWHwObVMS92ryhArik>
Subject: Re: [DNSOP] draft-ietf-dnsop-session-signal: session establishment
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2018 19:38:21 -0000

On 27 Jan 2018, at 18:16, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> Greetings. The -05 draft still has a complexity that I can can be easily fixed. In a few places, it says that a session can be established by the client sending a response-requiring DSO request message. For example, from section 4.1:
>   A DSO Session is established over a connection by the client sending
>   a DSO request message of a kind that requires a response, such as the
>   DSO Keepalive TLV (see Section 6.1), and receiving a response, with
>   matching MESSAGE ID, and RCODE set to NOERROR (0), indicating that
>   the DSO request was successful.
> 
> This logic requires a client to survey all the kinds of requests it knows to find one appropriate for establishing the session. It also requires the server to have to check the first message for any kind of response-requiring request message.

The intent was not that client software would make a run-time decision about how to initiate a DSO session.

The intent was that a client *implementer* would make a design-time decision about how to initiate a DSO session. And, of course, “I’ll send a Keepalive request,” is a perfectly good design-time answer to that question.

On the server side, the routine that generates and/or sends DSO response messages just needs to set a Boolean flag saying, “no-error response sent” (or, equivalently, “DSO session established”) when it sends a no-error DSO response.

For implementations of only the base DSO spec (not extensions that build on DSO), the only response-requiring DSO request message is Keepalive, so it degenerates to the simple scenario you proposed -- a DSO session MUST be established by the client sending a Keepalive message.

The reason we left the flexibility in the specification was to avoid putting unnecessary constraints on future uses of DSO that we haven’t anticipated yet.

Stuart Cheshire