Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-requirements-16

Joe Touch <touch@strayalpha.com> Sun, 18 November 2018 01:42 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EB5130E83; Sat, 17 Nov 2018 17:42:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVTMQIygyPrA; Sat, 17 Nov 2018 17:42:28 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AAA130E4F; Sat, 17 Nov 2018 17:42:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zYilWclGwP1O2zRKa7XQiHOIVm+OOhPIGxr5KX4dMJk=; b=LGSMu9yMS/0pqj6gPWa+fiPxz bDOQRCyLLDCNZXjbhLUp7l1miO9MnH29PJOyKrSFJ/E32nKP+GPGPpSaNuDA+UEUo+I31u65osP2G bRIN0LgvD8Z8ZkVbGSgoqKzXXRdDPBOH4LR4M/DxRGyz8iGA6DRHwgKvZ0FR70vEA4SoaUkAGhfOI DEpLett1lbchgYufk6iGILHtPnQhdqQ6rwRmR37o20U1zOrUHo8r95pWLT7+jiAWFrtLAFfiN1P7r M5O73l53Gdo1JUfE+E+U55vEZcgTuZ9Cgi6ov4y+HzKObn89z17pUsoEPhxY+hNNGpDAT3LwpK0PI LI2P1tpMQ==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50153 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gOC6V-002oEk-NQ; Sat, 17 Nov 2018 20:42:28 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A50E553-D577-45F9-94B0-F37A66637E29"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <154250516269.15956.17131342239124604403@ietfa.amsl.com>
Date: Sat, 17 Nov 2018 17:42:27 -0800
Cc: draft-ietf-dots-requirements.all@ietf.org, ietf@ietf.org, dots@ietf.org
Message-Id: <558F11EB-4EB9-4605-9A49-56066289A1C6@strayalpha.com>
References: <154250516269.15956.17131342239124604403@ietfa.amsl.com>
To: tsv-art@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/cIz57NGi0zewJVDEekrQI4mbr3s>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-requirements-16
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Nov 2018 01:42:35 -0000

Hi, all,
The following boilerplate was supposed to have been inserted automatically…
Joe

——
This document has been reviewed as part of the transport area review team's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors and WG to 
allow them to address any issues raised and also to the IETF discussion list for 
information. 

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please
always CC tsv-art@ietf.org <mailto:tsv-art@ietf..org> if you reply to or forward this review.
---

> On Nov 17, 2018, at 5:39 PM, Joseph Touch <touch@strayalpha.com> wrote:
> 
> Reviewer: Joseph Touch
> Review result: Ready with Issues
> 
> Transport issues:
> - The GEN requirements refer to signal and data channels; it should be more
> clear that these would be transport associations or connections, not
> necessarily separate port assignments - GEN-03 recommends transports that avoid
> HOL blocking, but that blocking can occur at any protocol layer (e.g., when
> using TCP as a tunneling layer or at the application layer) - SIG-001 – PLPMTUD
> should be used instead of PMTUD; PMTUD (relying on ICMP, which is often blocked
> and remains insecure) should be avoided. The PMTU of 1280 is relevant only for
> IPv6. The use of 576 should be more clearly indicated as applying only to IPv4.
> (note there is emerging PLPMTUD for UDP). - SIG-004 should address the use of
> TCP keepalives for TCP connections as a way to achieve heartbeats. - SIG-004 is
> self-contradictory, at first claiming that agents SHOULD avoid termination due
> to heartbeat loss then later saying they MAY use heartbeat absence as
> indication of defunct connections. Even though SHOULD and MAY can be used
> together this way, the advise is confusing. This is a case (see below) where
> the reasoning behind exceptions to SHOULDs are needed -- but the MAY clause is
> a far too trivial (and, based on our experience with BGP, incorrect) condition
> - DATA-002 should suggest protocols for security, at least indicating whether
> these need to be at a particular protocol layer (IP, transport, application),
> etc.
> 
> Other issues:
> - the document uses SHOULD without qualifying the conditions for exception
> 
> Nits
> - the abstract is too brief
> - Several requirements suggest that use of TCP avoids the need for separate
> congestion control; the same should be mentioned of SCTP and DCCP.
> 
>