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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 28 July 2022 14:40 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 C4190C13C226; Thu, 28 Jul 2022 07:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=gmail.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 aDXMEHrdNVnt; Thu, 28 Jul 2022 07:40:15 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 EA9EAC15A728; Thu, 28 Jul 2022 07:40:14 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id v28so1540356qkg.13; Thu, 28 Jul 2022 07:40:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lH/BTTfnfw0mpfnL1hoF++IzJ6lSiLFXGNpB0+U4qy0=; b=ZRuPXBFFWMbCY27OrPlJaa8EgFBS0Egdz5DOhjtzZ3MzPGIGhe63UMQjLxqTVhMTsP bS3FjofDFrIe3x/dLe0zTtefq6zStHWS5Dem6xOE35M/EtD8fukL099QupYyf5+D+jES OQrMrSTzm11HM+0Ho+17XKZuYGoKF+SFSe/Q8JgWAtqrvCsK1ujGtLhZSBb9auG0t+ko jI6P1AjsStFtHFNMHvA8xpSZxmnya5eOSFalWiPZB3RhXi9Cy2DDkStXFqgM7Mf4IAKX iNbW1VDdBVc8VnEp8Et2jO1uabgfloEnlW1Cl6Hds/olgM6PlZzm/2R9L31GdPxre+ga uwRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lH/BTTfnfw0mpfnL1hoF++IzJ6lSiLFXGNpB0+U4qy0=; b=0vUlXDtqbwvMnHbercE1+HvBwcrTHXaAi0kD4cjx3hZJdekrZGK7y3YADpyUlg3qsk okibFc74v4imzVSlofi137qODDvJoJsoAMDNAhQFqV8N1yvIuHVsD2hj30DtCmRx4USV K2bRTTkGWYVzOw8b3raMsUhmw7rHUJr8GVu/jo4AuYHw7dCXmuTCQNMDCeUB5mxz4NW/ hLdqbKsJYY6AU22hf9BxZ4gGH5QEOqKjvFTD7T2ASFU5YNzkN8XKNJFSxfgoVBZgG5AF KZauXQXxFYMDQNRwgRAG+a55xjKrUWMCpibykYfPhwULth9tKTai5oxZ0ylrwuOIPxSI 6seg==
X-Gm-Message-State: AJIora9HN0ai13/xqJlerAnP+5ihggFBXGbehvEzsKvQNZIxZIraqF3o 4H5OcLULVPttWlcF10SIJin0qlu0eRVTj+wbHYQ=
X-Google-Smtp-Source: AGRyM1tIauIq8DHLxhAdN51qBSbK4iA5WPfnvav2U+31jU03iFIQ2IayPpCkphsb//NeH5zq5yxf5tLTTX8JduR+eKE=
X-Received: by 2002:a05:620a:370b:b0:6b6:d59:fcab with SMTP id de11-20020a05620a370b00b006b60d59fcabmr21045102qkb.564.1659019213721; Thu, 28 Jul 2022 07:40:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BAQ4gBEC2-OQTHyv6BvEzKDWFVaG2qOAM2iaAf0T11qsMQ@mail.gmail.com> <CAFU7BASp+vPZUtEWvQcVEP=CNyKmySMUz_YmYiR5jMw+w7C_mQ@mail.gmail.com> <CAKKJt-es6=_tUZeJxf0WcO0NPbi04KZ_X_Xo_jpS36UufR6fiQ@mail.gmail.com> <14215_1658242101_62D6C435_14215_225_7_a429bc3ce0f345b1a50238b8eb9ac004@orange.com> <afbaec2f-4247-391e-dc2f-6417a1881ed8@tenghardt.net>
In-Reply-To: <afbaec2f-4247-391e-dc2f-6417a1881ed8@tenghardt.net>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 28 Jul 2022 10:39:47 -0400
Message-ID: <CAKKJt-f+=2Gc7JX-K-2VYfoZuQ5ii1_OPYKtKBbUQY7huAv2eQ@mail.gmail.com>
To: Reese Enghardt <ietf@tenghardt.net>
Cc: mohamed.boucadair@orange.com, Jen Linkova <furry13@gmail.com>, "panrg@irtf.org" <panrg@irtf.org>, panrg-chairs <panrg-chairs@irtf.org>, Krähenbühl Cyrill <cyrill.kraehenbuehl@inf.ethz.ch>
Content-Type: multipart/alternative; boundary="000000000000e8d82205e4de822d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/PpjOvijW6PmICzsO_Lcb5zof4Pc>
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: Thu, 28 Jul 2022 14:40:15 -0000

Hi, Reese and Mohammed,

This all makes sense to me. I'm slightly sad that I can't  use a term with
a rigorous definition (and PANRG has been defining terms for a while), but
as Reese says, people use the same term in different areas of networking
all the time ...

Thanks for sharing your thoughts!

Best,

Spencer

On Tue, Jul 19, 2022 at 3:40 PM Reese Enghardt <ietf@tenghardt.net> wrote:

> Hi Spencer, Med,
>
> Thanks Spencer for checking in.
>
> I agree with Med's assessment, and I would like to keep our term and
> definition.
>
> In the past, we used the term "path segment", for what is now a
> "subpath", in an earlier version of draft-irtf-panrg-path-properties.
>
> Further thoughts on the original email:
>
> >  […]
> >
> > 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.
> >
> In draft-irtf-panrg-path-properties, we use lots of terms which may have
> different/alternative meanings in other contexts, as stated in the
> Introduction
>
> https://www.ietf.org/archive/id/draft-irtf-panrg-path-properties-05.html#name-introduction-11
> :
>
> "As terms related to paths have been used with different meanings in
> different areas of networking, first, this document provides a common
> terminology to define paths, path elements, and flows."
>
> The above text, to me, means that even though many people already know
> what a link is and may not have the same understanding, we define "Link"
> in the context of draft-irtf-panrg-path-properties and PANRG as we do in
> Section 2.
>
> Then, people are expected to apply our Terminology section's definition
> for "Link" throughout the doc (and, ideally, for other PANRG docs as
> well), rather than any alternative definition that they may have in mind.
>
> Does that make sense?
>
> Do you think that draft-irtf-panrg-path-properties needs any further
> clarification on this?
>
>
> Best,
> Reese
>
>