[PANRG] Response to review (Re: Fwd: New Version Notification for draft-enghardt-panrg-path-properties-03.txt)
Theresa Enghardt <ietf@tenghardt.net> Thu, 05 December 2019 16:29 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 8B2BD120130 for <panrg@ietfa.amsl.com>; Thu, 5 Dec 2019 08:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 P6MuFCBZBF8z for <panrg@ietfa.amsl.com>; Thu, 5 Dec 2019 08:29:48 -0800 (PST)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C5B120145 for <panrg@irtf.org>; Thu, 5 Dec 2019 08:29:48 -0800 (PST)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id B4A20B8; Thu, 5 Dec 2019 17:29:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1575563386; bh=4pkeh8vAjQFIXp6Wk6CNyXYR/gSWagiKAmM5Z0EC1Tw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=fCIxoBtWezXpqrsbuLqS9mH/rPOQX6f2rIJ5XDDiuW8/UqhZVFCaH7qIhX8U5wfnr T1cSgKATYs/3io5EdEx1N6IdLePrTnon7pU44d9LY4QpUhOv1Grt9VuqaWbljFzgW9 Gh4Ux7vKVbzKaGOqzbr71Ver8eM42fbmz3gNeYl9n0A1Icb1+ZxZZ4R0zSeeWqVrzP 6bgjwCwmGu7mlsuRH3Y74FeLgVcllic7t/ALBI19uu3j33ThSoD/0bg7bOlLe2/0md e0B+O0TIQ4hWLV1CAH7RWJ/VCK/94+14hSI8HOMPk7wsVsVcMJNFXTKjRMxWUyXrdn wpzhypYtKfT0Q==
To: mohamed.boucadair@orange.com, "panrg@irtf.org" <panrg@irtf.org>
References: <157287814355.16535.7971683761713699918.idtracker@ietfa.amsl.com> <a0b58a5b-597f-4117-e398-4cdf25a5b2d3@inet.tu-berlin.de> <787AE7BB302AE849A7480A190F8B9330313DE917@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Theresa Enghardt <ietf@tenghardt.net>
Message-ID: <61fe3e21-3de4-df17-6a72-a2d4fe92ff20@tenghardt.net>
Date: Thu, 05 Dec 2019 17:29:45 +0100
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: <787AE7BB302AE849A7480A190F8B9330313DE917@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------7C289DA11FF8E41F43972DBB"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/sLQJkPxcPG4vEorRe9hslm-zaH8>
Subject: [PANRG] Response to review (Re: Fwd: New Version Notification for draft-enghardt-panrg-path-properties-03.txt)
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: Thu, 05 Dec 2019 16:29:52 -0000
Dear Med, Thank you for supporting adoption and for the additional inputs. Having discussed the inputs with my co-author, please find some initial responses below: On 26.11.19 16:52, mohamed.boucadair@orange.com wrote: > […] > > FWIW, you may find some additional inputs at: > > · pdf: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-enghardt-panrg-path-properties-03-rev%20Med.pdf > > > · doc: > https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-enghardt-panrg-path-properties-03-rev%20Med.doc > First, thanks for all the editorial comments, we think they help improve clarity, especially in some of the existing definitions. Then, we have some comments and questions about the possibility of adding more definitions or substantially extending our existing definitions. In the "Node" definition, we would like to highlight that a node can be physical or virtual, so we decided we wanted to give examples for both - so we'll put in "e.g., a physical machine or a service function" (and not virtual machine), because the service function is an example for a virtual node, so we'll have the machine be a physical one. Towards the end of the "Path" definition, there's a sentence on path visibility. We would like to make sure that the visibility aspect is clear in our definitions, but we are not sure yet whether adding this particular sentence is the best way to do it, as we already have a sentence on visibility right before. We'll consider how to phrase and possibly consolidate our definition in the next revision. Still as part of the "Path" definition, about the sentence with the visible paths being volatile and multiple paths being available: We are not sure whether this is still part of the path definition or whether this is already talking about how a host handles or discovers paths. Here we would like to be careful about the scope of our draft: The draft provides a terminology for path properties and paths, but does not attempt to answer the question on how we can discover such path properties and paths. Essentially, we are addressing question 1 in the Questions Draft, but not question 2, which talks about discovering path properties. Therefore, we would like to avoid talking about how to discover paths, path elements, or path properties in this draft if we can. Perhaps the content on discovering paths or nodes can be part of a different "Discovery Draft" to be written in PANRG. Or maybe to some extent they can be part of the Use cases section, as we already talk about invoking additional path elements to become part of the path. The above similarly applies to the "Discovered Node" - If you think we require this definition to be part of our base terminology to talk about paths and path properties, could you explain why, please? Also, if you or anyone else in the Research Group has any thoughts on the scope of this draft VS the discovery of paths and path properties, we'd love to hear them. The definitions of Reverse path and Symmetric path seem useful to us as part of a base terminology for path properties, so we'll include them. Thank you for the input on the "Use cases" section. We are going to revise this section based on input we got at IETF 106, and we will consider your feedback as well when doing so. As we revise our use cases section, we will consider whether to put any reference to them into the abstract or not. For the definition of the "Transport Protocols available" property, again, we are not sure we want to go into detail about how to discover or cache this property, so we would opt for less detail here. Best, Theresa
- [PANRG] Fwd: New Version Notification for draft-e… Theresa Enghardt
- Re: [PANRG] Fwd: New Version Notification for dra… mohamed.boucadair
- [PANRG] Response to review (Re: Fwd: New Version … Theresa Enghardt
- Re: [PANRG] Response to review (Re: Fwd: New Vers… mohamed.boucadair