Re: [DNSOP] Comments on draft-ietf-dnsop-session-signal-06

Stuart Cheshire <cheshire@apple.com> Mon, 19 March 2018 16:13 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 7483312E04F for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 09:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.33
X-Spam-Level:
X-Spam-Status: No, score=-4.33 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Y830wHNptBlb for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 09:12:59 -0700 (PDT)
Received: from mail-in2.euro.apple.com (mail-in.euro.apple.com [17.72.148.12]) (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 0EC6512DA00 for <dnsop@ietf.org>; Mon, 19 Mar 2018 09:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1521475973; x=2385389573; 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=mcEVXNajqi06/++nEqo+bZFlSq8VrHgops0CRa4lHAI=; b=SU+0yrDkN9l1hAw8aYc31tciFil9Arg8qoELjNdHEkDe/+xtftT0LKoluL/BLM1y D3aFGrxr2QHb85rNtwm/4Gcqih4O80yBMSEHBocJjc22D+ZSvPM2N7bTUbPpK/Vw I9q8F0zYl47e+tseN2OJoEmeXcMRxysp0drgTqb8WL6efztjJIfDSnjCXBRnI791 C29r0JZEWPJCg+0pdWA0Ctm6ZDrsO2rjenYqXgCI+rVlcz2G15pZMLCL+tPkAkBX oMUuKIEyE66R1d7iebG698ReXGuJ3TtXnZXEbtwRCIvvf/BkGPG0Uhl2iRv2Pbh5 a2tKo9kkDYbQ3XBwxWfJlQ==;
Received: from relay1.euro.apple.com (relay1.euro.apple.com [17.66.55.11]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Apple Secure Mail Relay) with SMTP id 39.9E.28874.581EFAA5; Mon, 19 Mar 2018 16:12:53 +0000 (GMT)
X-AuditID: 1148940c-d70db9e0000070ca-f9-5aafe185e116
Received: from crk-mmpp-sz04.euro.apple.com (crk-mmpp-sz04.euro.apple.com [17.66.12.168]) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id 23.11.32125.481EFAA5; Mon, 19 Mar 2018 16:12:53 +0000 (GMT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [17.235.206.100] (unknown [17.235.206.100]) by crk-mmpp-sz04.euro.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P5U00CHMIDF4HB0@crk-mmpp-sz04.euro.apple.com>; Mon, 19 Mar 2018 16:12:52 +0000 (GMT)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <BDC91C97-812E-4259-BEA1-87D0DC5388BD@vpnc.org>
Date: Mon, 19 Mar 2018 09:12:50 -0700
Cc: dnsop <dnsop@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <6FE0F3BD-3201-41A2-A042-201FF1533D0C@apple.com>
References: <BDC91C97-812E-4259-BEA1-87D0DC5388BD@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3445.5.20)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi6GTOrdv6cH2Uwc6jHBZ331xmsbi1/gur A5PHkiU/mTw+z77KHMAUxWWTkpqTWZZapG+XwJXx6ugj9oI5JhUNZ3czNTBO1+hi5OSQEDCR uN+4n72LkYtDSGAHk8T8j3dZYRL7t/1nhEhcY5S41LCFDSTBKyAo8WPyPZYuRg4OZgF1iSlT ciFq5jJJvN28HqxGWEBK4tXKz8wQtrPExoNvwWw2AS2JF5+vgNVwCthI3H/9hgXEZhFQldi8 4x+YzQzUO2nKPFYIW1viybsLrBB7bSSuzutjBLGFBKwlTrY8AouLCGhIXHi4gx3iaCWJ6d9v s4EcJCHQwSZx/NUN9gmMwrOQ3D0L4e5ZSFYsYGRexSiem5iZo5uZZ6SXWlqUr5dYUJCTqpec n7uJERTkHlN4djBePGh4iFGAg1GJh1fjzvooIdbEsuLK3EOMEhzMSiK8T6+sixLiTUmsrEot yo8vKs1JLT7EKM3BoiTOm/LYL0pIID2xJDU7NbUgtQgmy8TBKdXAOIHtYa14xdHGqFOdoaGF mS/cqgwSMx/uKNqvN73wmLSwjCpDtFLfz3Dnc4ebnX7+6rxjXPG/e6HY8vab+YWP3q2qfpd+ asuvt1ov2FZf4HvSl83X9mpDz84+j62lz096GEt3rLzzqOjdqZDX/Q/X1BUcrtkrkTihwccj s4Jvxo9s3b2s2Yd5lFiKMxINtZiLihMBrTtI824CAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUi6MSzQrf14foog1kt7BZ331xmsbi1/gur A5PHkiU/mTw+z77KHMAUxWWTkpqTWZZapG+XwJXx6ugj9oI5JhUNZ3czNTBO1+hi5OSQEDCR 2L/tP2MXIxeHkMA1RolLDVvYQBK8AoISPybfY+li5OBgFlCXmDIlF6JmLpPE283rwWqEBaQk Xq38zAxhO0tsPPgWzGYT0JJ48fkKWA2ngI3E/ddvWEBsFgFVic07/oHZzEC9k6bMY4WwtSWe vLvACrHXRuLqvD5GEFtIwFriZMsjsLiIgIbEhYc72CGOVpKY/v022wRGgVlITp2FcOosJFMX MDKvYhQtSs1JrDTUSy0tytdLLCjISdVLzs/dxAgOSnPuHYzHdxseYhTgYFTi4T1/a32UEGti WXFl7iFGCQ5mJRHep1fWRQnxpiRWVqUW5ccXleakFh9ilOZgURLntfXljxISSE8sSc1OTS1I LYLJMnFwSjUwujypMpe7FvjojtrBZ8LBh35JNWnb1pQLlRYtfBal9I3F6NCdU0vKPxu7Np/Z M+/mNO7tP19VCzzofjZN6P+9ebxMxsnHWs+rX/VIl79/Y8mu7+Kz30mts72ZbJZttpXZ/K7J jNl/kg3UfVd92xvqJCVu8FA1zILrUN0X0Z0xb5f8nn9h2YlbX5VYijMSDbWYi4oTAXeX8Z5G AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Z5Ipn2N-CKclNCmYYk1JY2vCJ3M>
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-session-signal-06
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, 19 Mar 2018 16:13:04 -0000

On 5 Mar 2018, at 14:56, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> This draft is much clearer about DSO unacknowledged messages, which really helps understanding the protocol. Also, thank you for switching from "octet" to "byte". :-)

Thanks for your feedback Paul.

> A few other comments:
> 
>   In this document the term "session" is used exclusively as described
>   above, and is in no way related to the anachronistic term "session"
>   as used in the obsolete "seven-layer model" that shaped the design of
>   the failed OSI protocols of the 1980s.
> 
> Judgmental language seems unneeded here.

Just a test to check if anyone was actually reading the draft :-)

It is now changed to this:

   In this document the term "session" is used exclusively as described
   above.  The term has no relationship to the "session layer" of the
   OSI "seven-layer model" popularized in the 1980s.

>   Note that for clients that implement only the DSO-TYPEs defined in
>   this base specification, sending a DSO Keepalive TLV is the only DSO
>   request message they have available to initiate a DSO Session.  Even
>   for clients that do implement other future DSO-TYPEs, for simplicity
>   they MAY elect to always send an initial DSO Keepalive request
>   message as their way of initiating a DSO Session.
> 
> It is unclear whether this is meant to place a restriction on future protocols that define new DSO-TYPEs. Assuming that it is, it might be clearer to say so explicitly.

I have updated the text as follows:

   <<Same text as above>>  A future
   definition of a new response-requiring DSO-TYPE gives implementers
   the option of using that new DSO-TYPE if they wish, but does not
   change the fact that sending a DSO Keepalive TLV remains a valid way
   of initiating a DSO Session.

> The second paragraph of Section 5.6.1 give an example that is much more detailed, and possibly conflicting with the (apparently normative) table in Section 4.2.1.
> 
>   |    9 | NOTAUTH   | Not Authoritative (TLV-dependent)              |
> 
>   An RCODE value of NOTAUTH indicates
>   that the server has been reconfigured and is no longer able to
>   perform one or more of the functions currently being performed on
>   this DSO Session because it no longer has authority over the names in
>   question.
> 
> The table entry says nothing about the server being reconfigured, nor about "no longer able" as compared to "was never able”.

You are right. This part of the document was not sufficiently thorough. I also realized it was unclear about what to do when there is more than one reason for the server wanting to end the session. I have updated the text as shown below:

6.2.1.  Retry Delay TLV used as a Primary TLV

   When sent from server to client, the Retry Delay TLV is used as the
   Primary TLV in an unacknowledged message.  It is used by a server to
   instruct a client to close the DSO Session and underlying connection,
   and not to reconnect for the indicated time interval.

   In this case it applies to the DSO Session as a whole, and the client
   MUST begin closing the DSO Session, as described in Section 5.6.1.
   The RCODE in the message header SHOULD indicate the principal reason
   for the termination:

   o  NOERROR indicates a routine shutdown or restart.

   o  FORMERR indicates that the client requests are too badly malformed
      for the session to continue.

   o  SERVFAIL indicates that the server is overloaded due to resource
      exhaustion and needs to shed load.

   o  REFUSED indicates that the server has been reconfigured, and at
      this time it is now unable to perform one or more of the long-
      lived client operations that were previously being performed on
      this DSO Session.

   o  NOTAUTH indicates that the server has been reconfigured and at
      this time it is now unable to perform one or more of the long-
      lived client operations that were previously being performed on
      this DSO Session because it does not have authority over the names
      in question (for example, a DNS Push Notification server could be
      reconfigured such that is is no longer accepting DNS Push
      Notification requests for one or more of the currently subscribed
      names).

   This document specifies only these RCODE values for Retry Delay
   message.  Servers sending Retry Delay messages SHOULD use one of
   these values.  However, future circumstances may create situations
   where other RCODE values are appropriate in Retry Delay messages, so
   clients MUST be prepared to accept Retry Delay messages with any
   RCODE value.

   In some cases, when a server sends a Retry Delay message to a client,
   there may be more than one reason for the server wanting to end the
   session.  Possibly the configuration could have been changed such
   that some long-lived client operations can no longer be continued due
   to policy (REFUSED), and other long-lived client operations can no
   longer be performed due to the server no longer being authoritative
   for those names (NOTAUTH).  In such cases the server MAY use any of
   the applicable RCODE values, or RCODE=NOERROR (routine shutdown or
   restart).

   Note that the selection of RCODE value in a Retry Delay message is
   not critical, since the RCODE value is generally used only for
   information purposes, such as writing to a log file for future human
   analysis regarding the nature of the disconnection.  Generally
   clients do not modify their behavior depending on the RCODE value.
   The RETRY DELAY in the message tells the client how long it should
   wait before attempting a new connection to this server instance.

   For clients that do in some way modify their behavior depending on
   the RCODE value, they should treat unknown RCODE values the same as
   RCODE=NOERROR (routine shutdown or restart).

   A Retry Delay message from server to client is an unacknowledged
   message; the MESSAGE ID MUST be set to zero in the outgoing message
   and the client MUST NOT send a response.

   A client MUST NOT send a Retry Delay DSO request message or DSO
   unacknowledged message to a server.  If a server receives a DNS
   request message (i.e., QR=0) where the Primary TLV is the Retry Delay
   TLV, this is a fatal error and the server MUST forcibly abort the
   connection immediately.

The updated draft is available at: <https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-07>

Stuart Cheshire