Re: [PANRG] A ping, and a post-RG Last Call question (was: Re: RG Last Call: draft-irtf-panrg-path-properties)

mohamed.boucadair@orange.com Tue, 19 July 2022 14:48 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 94D0CC18872B; Tue, 19 Jul 2022 07:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puM62DX9_-70; Tue, 19 Jul 2022 07:48:29 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F7BC16ECAA; Tue, 19 Jul 2022 07:48:23 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4LnMC96jydz7v68; Tue, 19 Jul 2022 16:48:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1658242101; bh=w7mjR0vVhA8elFpZxvkQvCelUC5uyia+Qrvs/w1Vgo8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=PIN8uSKh8ugmBR7oYUDQWS0OUiGo77Hu/18tM7mMnDexcFWpQnU6f5AYSXumbvrDb 72e6WOC81rCMVhGNjey4gbEYv1+CfkiKuUtULO+vWyiPm/MPq8MiGE3UDwNijb3F/4 D8gfwb50zo/irVdP4Sab61Feir8BUOHJYH16NFTQqRdkbUs+jsQM3IR0ZoWdQnmp6T FRUncr+ouReR4JTBcKAX4X8wwmojknqGWtXXwfT0d+tEnHUBopDpxDcQIuibahiH7Z M78YLTpVIO1+3wWWiW4PlWPODzObdwObYHQ9QX0skDuAxuyYWLeTjpC1WkeH2gnO9f iGwpUHEHmg5BQ==
From: mohamed.boucadair@orange.com
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Jen Linkova <furry13@gmail.com>
CC: "panrg@irtf.org" <panrg@irtf.org>, Theresa Enghardt <ietf@tenghardt.net>, panrg-chairs <panrg-chairs@irtf.org>, Krähenbühl Cyrill <cyrill.kraehenbuehl@inf.ethz.ch>
Thread-Topic: [PANRG] A ping, and a post-RG Last Call question (was: Re: RG Last Call: draft-irtf-panrg-path-properties)
Thread-Index: AQHYm3yxkFHz88HUUEueexgmo0I0yK2FxTng
Content-Class:
Date: Tue, 19 Jul 2022 14:48:21 +0000
Message-ID: <14215_1658242101_62D6C435_14215_225_7_a429bc3ce0f345b1a50238b8eb9ac004@orange.com>
References: <CAFU7BAQ4gBEC2-OQTHyv6BvEzKDWFVaG2qOAM2iaAf0T11qsMQ@mail.gmail.com> <CAFU7BASp+vPZUtEWvQcVEP=CNyKmySMUz_YmYiR5jMw+w7C_mQ@mail.gmail.com> <CAKKJt-es6=_tUZeJxf0WcO0NPbi04KZ_X_Xo_jpS36UufR6fiQ@mail.gmail.com>
In-Reply-To: <CAKKJt-es6=_tUZeJxf0WcO0NPbi04KZ_X_Xo_jpS36UufR6fiQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-07-19T14:47:56Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=629ba698-aa3d-4c40-a544-ea5c74e4b228; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.27.53]
Content-Type: multipart/alternative; boundary="_000_a429bc3ce0f345b1a50238b8eb9ac004orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/Sqkel_lC8IxImfAbU3UHNrbAUUg>
Subject: Re: [PANRG] A ping, and a post-RG Last Call question (was: Re: RG Last Call: draft-irtf-panrg-path-properties)
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.39
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: Tue, 19 Jul 2022 14:48:33 -0000

Hi Spencer, all,

> If we used the term "Path Segment", rather than Link, in our work, do people think


I’m not sure this is a good idea, especially that we define a path element as “Either a node or a link.”.



If you really need to point to a segment of a path, you may consider using “Subpath”.



Cheers,

Med

De : Panrg <panrg-bounces@irtf.org> De la part de Spencer Dawkins at IETF
Envoyé : mardi 19 juillet 2022 16:34
À : Jen Linkova <furry13@gmail.com>
Cc : panrg@irtf.org; Theresa Enghardt <ietf@tenghardt.net>; panrg-chairs <panrg-chairs@irtf.org>; Krähenbühl Cyrill <cyrill.kraehenbuehl@inf.ethz.ch>
Objet : [PANRG] A ping, and a post-RG Last Call question (was: Re: RG Last Call: draft-irtf-panrg-path-properties)

Dear Fans of All Things Path-related,

On Wed, Apr 20, 2022 at 2:42 AM Jen Linkova <furry13@gmail.com<mailto:furry13@gmail.com>> wrote:
The RG Last Call for
https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ has
ended - thank you everyone who read the document and provided
feedback.

Reese, Cyrill - my understanding is that you are going to publish the
revised ID to address the comments.

I don't know if this is a useful question to ask, at this point in the approval process, so "not helpful, wontfix" would be a fine response, BUT

I would like to use PANRG terminology in a response to reviewer comments on  https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/179, and I don't think our use of "link" is as helpful as I wish it was.

I think our definition of Link is actually Mostly Fine,

A medium or communication facility that connects two or more nodes with each other. A link enables a node to send packets to other nodes. Links can be physical, e.g., a Wi-Fi network which connects an Access Point to stations, or virtual, e.g., a virtual switch which connects two virtual machines hosted on the same physical machine. A link is unidirectional. As such, bidirectional communication can be modeled as two links between the same nodes in opposite directions.

but the NAME seems unhelpful, because many people already know what a link is, and they may not all have the same understanding about that.

draft-irtf-panrg-path-properties knows what a Path is (duh), and knows what a Subpath is.

If we used the term "Path Segment", rather than Link, in our work, do people think

  *   That would be helpful?
  *   That would be wrong?
  *   That would be a fine thing to have brought up several years ago, but that ship has sailed?
I'm probably going to use the term Path Segment in the MOPS document I pointed to above, but wanted to ask about the terminology here.

Best, and I look forward to seeing you folks in real life next week (where Meetecho counts as "real life", for some of us),

Spencer

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.