Re: [PANRG] RG Last Call for draft-irtf-panrg-questions

Theresa Enghardt <ietf@tenghardt.net> Sun, 05 July 2020 23:54 UTC

Return-Path: <ietf@tenghardt.net>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AD53A0C1A for <panrg@ietfa.amsl.com>; Sun, 5 Jul 2020 16:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DOS_RCVD_IP_TWICE_B=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net
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 NtJhYJ7axEqb for <panrg@ietfa.amsl.com>; Sun, 5 Jul 2020 16:54:35 -0700 (PDT)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6980A3A0BF5 for <panrg@irtf.org>; Sun, 5 Jul 2020 16:54:34 -0700 (PDT)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 90E17AA for <panrg@irtf.org>; Mon, 6 Jul 2020 01:54:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1593993272; bh=abR6xvjZ6Tgk2sAf1jIguIcMfH0PBnemn2JxJ8QiqFU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Tftb9WU0/yhpAPW5h8pMprq+0rgkoVy8eqWJuJbqc0vBqwVPFuUqWZWqKWmf0OyXD jxAYOcGbcu6X1pqgz7VlXITj4zFGzrgnqlxVmJJlclRNsUu2soBi0lsPccg+5BfTrE Dn/pCxLHoHJLfWgW9jW5jMhROgu10yiWG7QaLwiqFf+403ldqJvhUx2sqdKc9Mbfl+ 5QXUB7XLSeKU/G4EVoYsMHo84nH9+bcu07195SjRezydez1phXjkhQmai9p/PZsyPZ mntc6E127Wm7J5GYYW0JUPzx6UJE3OLH1a13wRyMaaDW6nnE/xdT+00cPjkFmSdosL 4rDBIxR42cWyw==
To: panrg@irtf.org
References: <CAFU7BAQc2UnN6mNpYF6e1UGRiz=5J3_n_n-Z9YE39RK6683ZfA@mail.gmail.com>
From: Theresa Enghardt <ietf@tenghardt.net>
Message-ID: <11e92cb9-9574-8579-1a9c-83ad7f3a91b2@tenghardt.net>
Date: Sun, 05 Jul 2020 16:54:28 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAFU7BAQc2UnN6mNpYF6e1UGRiz=5J3_n_n-Z9YE39RK6683ZfA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/LAb1h_HnCbwSwGLmB0I0aMgeKm0>
Subject: Re: [PANRG] RG Last Call for draft-irtf-panrg-questions
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Jul 2020 23:54:38 -0000

Dear PANRG,

I just read this document again and I think it's ready for publication.

In fact, I think this document nicely captures the key questions that
we're working on in PANRG, and I expect this to be interesting to people
outside of PANRG as well, so it really should be published.


Just a couple of nits that I found:

- Typo in abstract: "intetnetworks"

- Normative vs informative references: It's not clear to me why RFC 4302
(IP Authentication Header) and RFC 5246 (TLS 1.2) are Normative, while
RFC 7624 (on Passive Surveillance) and RFC 8170 (on Protocol Adoption
and Transition) are Informative. Maybe all of these should be Informative.

- For TLS, perhaps the reference should be updated to TLS 1.3.


Finally, one suggested addition:

Section 2.3, "Supporting Path Selection", states that "Path selection
   must, like path property information, be trustworthy, such that the
   result of a path selection at an endpoint is predictable."

I think it might be worth noting that results should not only be
predictable, but should also result in an outcome that is "better than
the default" or "better than random". Maybe surprisingly, this is not
trivial, as we also noted the Path Properties draft (Section 3.1) after
somebody (I forget who) brought up this point in a PANRG session.

I suggest to add something like the following phrase:

"Moreover, any path selection mechanism should aim to provide an outcome
that is not worse than using a single path, or selecting paths at
random, e.g., in terms of performance."


Best,
Theresa