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

["Paul Hoffman" <[e-mail]>]

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