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

Suresh Krishnan via Datatracker <noreply@ietf.org> Wed, 01 May 2019 20:34 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 2EE8112004F; Wed, 1 May 2019 13:34:39 -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-data-channel@ietf.org, Roman Danyliw <rdd@cert.org>, dots-chairs@ietf.org, rdd@cert.org, 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: <155674287918.725.5059294278452219173.idtracker@ietfa.amsl.com>
Date: Wed, 01 May 2019 13:34:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/ctbcNiJrMqRGLN6tK8K6YJHt1Ow>
Subject: [Dots] Suresh Krishnan's Discuss on draft-ietf-dots-data-channel-28: (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 20:34:39 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-dots-data-channel-28: 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:


* Section 4.3

The processing requirements for the tcp flags bitmask is not at all clear.
Specifically how should an implementation use the values in the flags, operator
and the bitmask fields in the tcp subtree to figure out if a given packet
matches. An example here could be very helpful.

"Bitmask values can be encoded as a 1- or 2-byte bitmask."

How? The bitmask field is a uint16. How would a client indicate a 1 byte

[Also note that there are *nine* flags defined for TCP including the
experimental NS bit that occurs as bit 7 of Octet 12 and a 1 byte bitmask will
not catch them all]


How does the flags field in the ipv4 match subtree interact with the bits in
the fragment side? I can easily see that someone can make a mistake due to this
redundancy and come up with something that is not coherent. e.g. bit "more"
under flags is set and bit "lf" under fragment-> type is also set .