Re: [DNSOP] Spencer Dawkins' Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

Ted Lemon <> Tue, 31 July 2018 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68D0C130E73 for <>; Tue, 31 Jul 2018 13:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[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 iUQPg0kktMDq for <>; Tue, 31 Jul 2018 13:35:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A202130E0C for <>; Tue, 31 Jul 2018 13:35:48 -0700 (PDT)
Received: by with SMTP id m13-v6so17502433qth.1 for <>; Tue, 31 Jul 2018 13:35:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ufDTcCqgDhIsxY2XA/6UzeRmJ6N637//TnglYY6tikU=; b=UvRnKlhAoMxaCraqgA06JoC7p/4mqAcaGCtLfq3X1t4FDcklB4NSdkJdIlKcazBbLY 7vyx9P0TMp1FzvP4odaWhFQ4eZX894O2VIu4Pj8MnFOa9Asj7GU8qB/3YqagTiV2tPAp +/GZwSREyFxgf1ub80T6bYxqZGmXCyamXyEWLgJ9yczPmONgCX+mH0R8p1kE5UixV9fq eCBLMF3utIz84uft4/VA3NX0ptVJEvIgp9pg8cuQSa00ftvFF+QVzE5JKOxzj0EEWkAl ry22APCaKIWLFH6/FUYp6l0r7kbFSDY3XueHcyWEQof0hRV/qzunuWES7Ljh1JIUSKGh RgRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ufDTcCqgDhIsxY2XA/6UzeRmJ6N637//TnglYY6tikU=; b=hcZUGYnU2kOLUaBg7QXsuTFycw4JIyEKw11ZLf0+mn8eXW35ub249x36ubaa6KTmRv us2p84hBuo/jlUXHyaKpl+9j9RJY4mYpPecU92FFoVY82HLaOOrvGsLC8IFi4xWR0GVf SSlyv2/ODQUYDLSzLTSLxh77AZJwu46UV3936RD17Wf2BaDem4MYA0vqv6piFkWqmoYd 1alwy9CxPCR2u9fqwQH0eWQtUtdlaFNPjXZ5F80ESTtYnMeNj9h0kTs9aHEBzr1a+uDg PIpkoyXC2YHv05QZsGmVtdD7/6uSEgYWfjlXTfBoMNV1zQa6nWlpwXMQQagCqpaxdkZ5 XKIQ==
X-Gm-Message-State: AOUpUlHoAH1MjlGfucLw1G5fy5JgQ9K6Yz844DXq29TazoIUnmMlipz0 SPiWxhgkhbECf8r8jy4rq8CJAw==
X-Google-Smtp-Source: AAOMgpchipZNWNlGYFL8o4xtGsMD6TRUT5V54b3dWiprUIOrM+v5qEfmiKfxwegrE8xBWgWyp+UWbg==
X-Received: by 2002:a0c:ca94:: with SMTP id a20-v6mr20624273qvk.37.1533069347509; Tue, 31 Jul 2018 13:35:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id n84-v6sm9854873qke.68.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 13:35:46 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1A4575BC-380F-4350-BCB4-1041C06625F6"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.17\))
Date: Tue, 31 Jul 2018 16:35:45 -0400
In-Reply-To: <>
Cc: The IESG <>,, Tim Wicinski <>, dnsop-chairs <>,
To: Spencer Dawkins <>
References: <> <>
X-Mailer: Apple Mail (2.3445.100.17)
Archived-At: <>
Subject: Re: [DNSOP] Spencer Dawkins' Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jul 2018 20:35:51 -0000

On Jul 31, 2018, at 2:41 PM, Ted Lemon <> wrote:
>  The client may perform as many DNS operations as it wishes using the
> -newly created DSO Session. Operations SHOULD be pipelined (i.e., the
> -client doesn't need wait for a response before sending the next message).
> +newly created DSO Session. When the
> +client has multiple messages to send, it SHOULD NOT wait for each response before sending the next message.
> +This prevents TCP's delayed acknowledgement algorithm from forcing the
> +client into a slow lock-step.
>  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.
> +when responses to those messages become available out of order, the server
> +SHOULD NOT delay sending available responses in order to respond in order.

As a result of the discussion on Benjamin's DISCUSS, I noticed that we don't reference RFC7788 here, and this text mirrors section 3.3 of RFC778, so I added a line after this that explicitly references that section.