Re: [DNSOP] Genart telechat review of draft-ietf-dnsop-session-signal-11

Ted Lemon <> Thu, 05 July 2018 22:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 681D512777C for <>; Thu, 5 Jul 2018 15:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KFnGc2BQdYOg for <>; Thu, 5 Jul 2018 15:14:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35355130DD5 for <>; Thu, 5 Jul 2018 15:13:58 -0700 (PDT)
Received: by with SMTP id u4-v6so14073554itg.0 for <>; Thu, 05 Jul 2018 15:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tptSMorVffAfjcZWj0B/XX8fn1XjLtqAVp0ww0XxxYg=; b=DA93dv8kIwKJ2IIA5wPtBvzLVqsKJjN3zAvBwGqPGJBw9ZKRzfP5yA6+IV9Btzys2H H1HOOxXmnONToRi8rde00zhyi1fzIwccF99vKH1wt0JVLoUzisIjsRwWNYzv61DBrhgZ 9jcK2QHKidZF0Eo39ai4ALsSaj3BbzmN6qN3toTWgYcxBc1mCncTYYc8q6tHr8m175Yq M4h7EVgcNdILNx7Vm4QzvGJ1lVWWa8IJ7f1pMfz5zyBgMi7S0oiQcKw7YU9WNTLeiLma tzhZFsYk4ngk+GVQCuJaxo4pM1G+Ha54MYFN6mHSoFfyF1qF+O6mnCTsoBItr+6BNfuw JL2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tptSMorVffAfjcZWj0B/XX8fn1XjLtqAVp0ww0XxxYg=; b=oWYQx54gO6C7uyFSs8gCMOK7mjWBiCYgkiMPG1kF2d04Xf1cCzcvcxlu0eUtpdqcMp nzfSu8xe+owUHZjz8DWMXUjRXTtP4D53vBNTDaVR9tjnWspNkbHRWU8uVxrdHAvHFiJf BiPlDrWeEobV7LhlAfZQsAqTm/AbPpuGCE5Y3zbJYyo3dLppkOlbdngyVRWd5mt2AXF1 AR/Y8nczaUpn5ZDeD0BDjTxdr9kNZmkJvqkFjabtx9VjZ3xBxjPu9UD4oevGZvjC3MIA 2tg3EmoFKMkq5F0JFPUao6jW7wmf81hNg+BeUhUVL4Zr+Yufhov2Kujd9xQ8vejrAMOm ZhHg==
X-Gm-Message-State: APt69E0dymPvqV5tkoXNXp7w5SFiWWCxKklHcMEj2/jizjLi3n9igHen v25ZKSidg91jM++W9LCln/yUZr6/yBMkgLVnca8Odg==
X-Google-Smtp-Source: AAOMgpemp+UVUQ29L9UzMCcJHOLr6L0PdrcK3x5kJhQfNZ+jkQ80zIc6jhJ0bfAPWjEo1SUv3/tKwy6lmOeLOnAMwYE=
X-Received: by 2002:a02:1bdc:: with SMTP id 89-v6mr6313547jas.72.1530828837377; Thu, 05 Jul 2018 15:13:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 15:13:16 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Lemon <>
Date: Thu, 5 Jul 2018 18:13:16 -0400
Message-ID: <>
To: Joel Halpern <>
Cc: General area reviewing team <>,, dnsop WG <>, ietf <>
Content-Type: multipart/alternative; boundary="000000000000106e72057047ddc9"
Archived-At: <>
Subject: Re: [DNSOP] Genart telechat review of draft-ietf-dnsop-session-signal-11
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jul 2018 22:14:04 -0000

Joel, it's immaterial whether the DSO engine responds in time or not.   If
it responds in time, the ack and the response will be combined; if it does
not, then Nagle's algorithm will ensure that the ack goes out, and the
response will go out in a later packet.   Either outcome is fine.   There
is no need to caution the implementor that they should ensure a quick
response—if they don't care to get the response out in 200ms, they
obviously don't care about performance, and that's perfectly fine.   It is
absolutely *not* a requirement that they do so.   The point of this text in
the document is to inform implementors that *do* care about performance
about the interaction between Nagle and DA.

We looked at your comment about middleboxes and couldn't figure out what
problem you are trying to solve here.   If a middlebox is not DSO-aware,
it's going to prevent DSO from working (which would be correct), or else
forward it unchanged (which would also be correct).   The text is an
admonishment for implementations that are DSO-aware.   If an implementation
is not DSO-aware, then adding text to instruct the implementor, who
presumably will not read it, doesn't make sense.

Your proposed change to 5.2.2 seems fine to me—I don't remember what
happened with that.

On Thu, Jul 5, 2018 at 5:48 PM, Joel Halpern <> wrote:

> Reviewer: Joel Halpern
> Review result: Ready with Nits
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-dnsop-session-signal-11
> Reviewer: Joel Halpern
> Review Date: 2018-07-05
> IETF LC End Date: 2018-06-25
> IESG Telechat date: 2018-08-02
> Summary: This document is ready for publication as a Proposed Standard RFC
> Some of my earlier comments have been addressed.  It appears that an
> effort was
> made to address more, but I was apparently unclear.  I have copied the
> comments
> that seem to still apply, with elaboration.  If I am still unclear, please
> contact me.
> Major issues: N/A
> Minor issues:
>     Section 5.1.3 places some requirements on application level
> middleboxes,
>     and includes a very clear explanation of why it places these
> requirements.
>     While it may be "obvious" to one who lives and breathes DNS, I think it
>     would help to explain why the usual operation of an existing middlebox
> will
>     (typically? always?  inherently?) meet this requirement.  To rephrase,
> the
>     text says things like "the middlebox MUST NOT blindly forward DSO
> messages
>     in either direction." Apparently, somehow, the existing world
> middleboxes
>     will do comply with this.  How?
>     The third and fourth paragraphs of section 5.2.2 do not talk about
> optional
>     additional TLVs.  It would be helpful if the document stated that in
>     addition to those additional TLVs required by the primary TLV, other
> TLVs
>     may be included based on their individual definition, independent of
> the
>     definition of the primary TLV.  (Both the Encryption padding and the
> delay
>     retry TLVs may be included in suitable messages without being called
> out in
>     the definition of the primary TLVs.)
>     An effort appears to have been made to address this, which suggests I
> was
>     unclear.  The text says:
>         A DSO response message may contain no TLVs, or it may be specified
> to
>         contain one or more TLVs appropriate to the information being
>         communicated.
>     The definition of the specific response messages does not discuss the
>     encryption padding or delay response TLVs.  They are clearly intended
> to
>     be allowed.  So can we tune the text to make that clear.  I think the
>     intention is that the specification of the response message indicates
> which
>     TVLs are required, and that others are allowed.  So say that.
> Nits/editorial comments:
>     Section 5.4 talks about by default the TCP data ack and the DSO reply
>     message being combined.  Doesn't this depend upon the responsiveness
> of the
>     DSO engine?  Is there an implicit assumption about such timeliness
> (sub 200
>     ms)?
>     I suspect from the lack of comment on this that I am missing something
>     obvious?