[DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

Ben Campbell <ben@nostrum.com> Wed, 01 August 2018 23:03 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5547A130EA2; Wed, 1 Aug 2018 16:03:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dnsop-session-signal@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153316460033.22111.15407765170002738455.idtracker@ietfa.amsl.com>
Date: Wed, 01 Aug 2018 16:03:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zWeqROOb6Z66W-ydrZrEQ8lrH18>
Subject: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 01 Aug 2018 23:03:20 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-dnsop-session-signal-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

§5.1,"
   If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
   ([TBA2] tentatively 11), then the client MUST assume that the server
   does not implement DSO at all.  In this case the client is permitted
   to continue sending DNS messages on that connection, but the client
   SHOULD NOT issue further DSO messages on that connection."

Why is the SHOULD NOT not MUST NOT? Do you envision situations where it might
make sense to violate the SHOULD NOT?

§5.1.2: Are there security considerations for using zero round trip handshakes?

§5.1.3: "In cases where a DSO session is terminated on one side of a
   middlebox, and then some session is opened on the other side of the
   middlebox in order to satisfy requests sent over the first DSO
   session, any such session MUST be treated as a separate session."

By what? How would the ultimate endpoints know?

§5.2.2.4: "
   If DSO unacknowledged message is received containing an unrecognized
   Primary TLV, with a zero MESSAGE ID (indicating that no response is
   expected), then this is a fatal error and the recipient MUST forcibly
   abort the connection immediately."

Doesn't that make extensibility difficult? What if an extension adds a new
unacknowledged message type that uses a new primary TLV?

§6.1: "The server MUST act on messages in the order they are
   transmitted, but responses to those messages SHOULD be sent out of
   order when appropriate."

The SHOULD seems more like a MAY, unless you mean for implementors to go
looking for reasons to do things out of order.

§6.4.1: Does "consider delinquent" entail any concrete actions beyond resetting
the connection?

§12.2: It seems like TLS1.3 should be a normative reference, given that it's
used to describe the condition for a normative statement.

Editorial Comments:

- General: Please watch for comma splices.

§1:
-- " It is likely that future updates to these tools will add the ability to
recognize, decode, and display the DSO data." That sentence may not age well.
-- " A goal of this approach is to avoid the operational issues that have
befallen EDNS(0), particularly relating to middlebox behaviour." Is there
something that can be cited to describe the operational issues?

§2: There's a fair amount of procedure, including normative statements,
described in the terminology section. That would better reserved to the
sections that are more about procedure. Some readers only use terminology
sections to look up terms on demand; such users may miss the procedure bits.

§5.1, "DSO messages MUST be carried in only protocols "
"MUST ... only" constructions can be ambiguous. Consider reformulating into a
"MUST NOT" construction.

§5.1.3:
-- 3rd paragraph: Should "stateless" be "stateful"?
-- "will have no way to
   know on which connection to forward a DSO message, and therefore will
   not be able to behave incorrectly."
That seems like famous last words :-)

§5.2.3, first paragraph: The MUST NOT seems more like a statement of fact.

§5.3: The section has a number of redundant normative keywords.  Please
consider stating them authoritatively in one place, and making the others
descriptive