[Dots] Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

Suresh Krishnan via Datatracker <noreply@ietf.org> Wed, 01 May 2019 03:06 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29B12004C; Tue, 30 Apr 2019 20:06:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-signal-channel@ietf.org, Liang Xia <frank.xialiang@huawei.com>, dots-chairs@ietf.org, frank.xialiang@huawei.com, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Suresh Krishnan <suresh@kaloom.com>
Message-ID: <155668001610.28771.2924259500369474716.idtracker@ietfa.amsl.com>
Date: Tue, 30 Apr 2019 20:06:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/CemxPteOG87CcfLs-mRKtj-LX3U>
Subject: [Dots] Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 May 2019 03:06:56 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-dots-signal-channel-31: Discuss

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-dots-signal-channel/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be easy to clear up, but I would like to understand why this
document needs to restate the motivation and describe the algorithm for happy
eyeballs instead of simply stating that hosts should use RFC8305 and then
specify that UDP must be tried before TCP in each of the address families. If
you do want to specify the whole algorithm here it needs to be more specific
than "in a manner similar to the Happy Eyeballs mechanism" as it is not clear
where it is similar (and where it will differ). It also looks like the example
flow in Figure 4 is not consistent with the description before (TCP+IPv6 before
UDP+IPv4)


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

* Section 7.3

This text is wrong and needs to be removed

"IP packets whose size does not exceed 576 bytes should never need to be fragmented"

RFC791 only requires all hosts to be prepared to accept datagrams of up to 576 octets.