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

"Paul Hoffman" <paul.hoffman@vpnc.org> Mon, 05 March 2018 22:57 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 4E98212EACC for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 14:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 j4G1hdgEYWuS for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 14:57:08 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 6DCBB129BBF for <dnsop@ietf.org>; Mon, 5 Mar 2018 14:56:54 -0800 (PST)
Received: from [10.32.60.149] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w25MuO08015866 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dnsop@ietf.org>; Mon, 5 Mar 2018 15:56:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.149]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: dnsop <dnsop@ietf.org>
Date: Mon, 05 Mar 2018 14:56:51 -0800
X-Mailer: MailMate (1.10r5443)
Message-ID: <BDC91C97-812E-4259-BEA1-87D0DC5388BD@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kQmggi3OorFkktUeLrOUEu1VKTw>
Subject: [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, 05 Mar 2018 22:57:14 -0000

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

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. Proposed replacement:

    In this document, the term "session" is used exclusively as 
described
    above, and is in no way related to other uses of the term "session"
    such as the "session layer" in the OSI model.

=====

    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.

    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.
    Future specifications that define new DSO-TYPEs MUST NOT require
    that those DSO-TYPEs be used to initiate a DSO Session. That is,
    future specifications MUST allow sending an initial DSO Keepalive
    request to initiate 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".

=====

Hope this helps!

--Paul Hoffman