Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-ietf-ippm-ioam-deployment-05> for your review
"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Thu, 13 April 2023 06:17 UTC
Return-Path: <fbrockne@cisco.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD09C159495; Wed, 12 Apr 2023 23:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b="hoNrq9K2"; dkim=pass (1024-bit key) header.d=cisco.com header.b="BqETaPVI"
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 gnnYnbolBbb6; Wed, 12 Apr 2023 23:17:41 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D2AC152A3E; Wed, 12 Apr 2023 23:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60550; q=dns/txt; s=iport; t=1681366660; x=1682576260; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MKS+oxjiPZ6gQWR1AeEyc/WISCD4hdz9EbieIsUDnac=; b=hoNrq9K2Agj9JurIJqku61AKX9GATwdU3LciE8bAY2YDt1y0pRuKQBWD LbjV3UKEVMc28GUx1uQ/BtxP4/K1AdPV4f186OZv6L9XuZ2Vrky5BNbhr rj8jDoLzmyYJ0L3WNnS6kGN50BjYE6+HoaYTS9lwci7XoPnW2Q5dvq5bw A=;
X-IPAS-Result: A0ABAAAjnTdkmBbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAJYEWBAEBAQEBCwGBW1JzAlkTKEaEUoNMA4RPX4gwA4tLhVSGJ4E4hF4UgREDVg8BAQENAQE5CwQBAYUGAhaFJyY0CQ4BAgICAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBAQEBHhkFEA4nhWgNhgMBAQEBAQEBEggBCAQNDAEBLAsBCwQCAQYCDgIBBAEBAQICERUCAgIfERUICAIEAQ0FCBMHglwBgigDDiMDAQ8GkCWPPQGBPwKKIHp/M4EBgggBAQYEBYE3AZsVDYJHCYEULQGHRoFGFIFSggAXgX2BIoERQoFJRIEVQ4FmgQI+giBCAgEBgRcEBgMBBAELAQYBIz2DHDmCLoEMiS6BWYMtgiCIbwqBNHaBIA6BPIEEAgkCEUMogRAIaoF5QAINZAsOb4FJgyoEAhRFFjcDRB1AAwtwPxQhFCAFBFVrLiQFAwsVKkcECDgGGzQRAggPEg8GJkQOQjczEwZcASkLDhEDUIFHBC83C4EbAgQBJiSeHhABEgJGBisTAhkIAwQNBxMBCgkICAYCFA4sASwVCCsKEQEeBQEFCwECEgQTCY0UhSkUEQkKLYJbAUegOYs6CT5vCoN+hXqFeI4IgQaGIxeDfUyBCYsRAwGGZ4YyhC+DZ4JKYpd0IIIuiwWDbpEgBA4LARGBUYMVAgQCBAUCDgEBBoFjOmtwcBUaIYIzATMJSRkPjiAMDQkVgRWCJoUUimV1AgEBOQIHAQoBAQMJhkuCIQEnBIFOXwEB
IronPort-PHdr: A9a23:0WY0GRY1xvPr7WqL+rtiA/n/LTDihN3EVzX9orIuhqgLdbys4NG5e kfe/v5qylTOWNaT5/FFjr/Ourv7ESwb4JmHuWwfapEESRIfiMsXkgBhSM6IAEH2NrjrOgQxH d9JUxlu+HToeVNNFpPGbkbJ6ma38SZUHxz+MQRvIeGgFITIiM+00e2a8JzIaAIOjz24Mvt+K RysplDJv9INyct6f78swwHApGdJfekeyWJzcFSUmRu9rsvl9594+CMWsPUkn/M=
IronPort-Data: A9a23:wl9ZBKqK2/ZQO6Dx7cIWmMOZjw5eBmIhZRIvgKrLsJaIsI4StFCzt garIBmAOqnfNzHxct12PIyz80NVvZHXydFqTwRupSs1RS4X8uPIVI+TRqvS04x+DSFioGZPt Zh2hgzodZhsJpPkjk7xdOKn9BGQ7InQLpLkEunIJyttcgFtTSYlmHpLlvUw6mJSqYDR7zil5 JWj86UzBHf/g2Qvaj5NsfrYwP9SlK2aVA0w7wRWic9j5Dcyp1FNZLoDKKe4KWfPQ4U8NoZWk M6akdlVVkuAl/scIovNfoTTKyXmcZaOVeS6sUe6boD56vR0SoPe5Y5gXBYUQR8/ZzxkBLmdw v0V3XC7YV9B0qEhBI3xXjEAexySM5Gq95eeBl2Cg9yjy3HpUCHW+fd+VFo4DJQXr7Mf7WFmr ZT0KRgEYwrGjOWszffqDOJtnc8kasLsOevzuFk5kmqfVqZgG8iYBf+QjTNb9G9YasRmE/zEY MEabzdHZxXbaBoJMVASYH47tLn52CWgK2UwRFS9hvop7TDykCtN+7nBb9f4eISUZuFltxPNz o7B1z2pXk5FXDCF8hKM726s2r/Ghyj7WZwfPKe2/btnjFyPwXZVDwcZPXOhr/L8h0K/R9VFA 1Ya8W8joaku81btScPyNyBUu1aNswRZWsJXCfF/7giRjKHV+A2eQGMDS1atdeDKqudvYhkX5 E+5m+/GJmZVir+FEWmTx66b+Gba1TcuEUcOYioNTA0g6tbloZ0ugh+ncjqFOPPq5jESMWyoq w1mvBTSlJ1O1ZZWh/nTEUTv2mP9/cSTJuIgzlyPBjrN0+9vWGKyT7SMgbQxxdVaJYWeUTFtV 1Bfwo3GtLBm4X2lsCGWW+gXVImu4/+DPFXhbb9T83sJqm3FF52LJN44DNRCyKFBbp5sldjBO hW7hO+pzMUPVEZGlIcuC25LN+wkzLL7CfPuXe3OY9xFb/BZLVHXpXo0ORTLhDG9ziDAdJ3T3 7/GIK5A6l5HVsxaIMaeHI/xLJdynHllnDOPLXwF50X7jNJym0J5uZ9cYAfRMYjVHYuPoR7e9 J5EJtCWxhBEONASkQGJmbP/2WsidCBhbbiv8pQ/XrfacmJORjp7Y9ePmuxJRmCQt/kP/gs+1 ivjChYwJZuWrSCvFDhmnVg4Me2zA8Yl9xrW/0UEZD6V5pTqWq72hI83fJosdr5h/+tmpcOYh dFcEylcKpyjkgj6xgk=
IronPort-HdrOrdr: A9a23:TqcSV6q94LfH8PjAaQeBBY0aV5uVL9V00zEX/kB9WHVpm5Oj5q OTdaUgtSMc1gxxZJh5o6HwBEDhexzhHZ4c2/hpAV7QZniXhILOFvAt0WKC+UyuJ8SazJ8+6U 4OSdkCNDSdNykcsS++2njHLz9C+qjHzEnLv5aj854Fd2gDAMsMg3Yde2Km+w9NNXZ77PECZe KhD7981kCdkAMsH7+G7xc+Lo7+Ttvw+q7OUFojPVoK+QOOhTSn5PrRCB6DxCoTVDtJ3PML7X XFuxaR3NThj9iLjjvnk0PD5ZVfn9XsjvFZAtaXt8QTIjLwzi61eYVaXaGYtjxdmpDs1L9qqq iIn/4TBbU115rjRBDynfIr4Xi47N8a0Q6n9bZfuwq6nSW2fkNgNyMLv/MrTvKQ0TtTgDg76t MK40uJ85VQFh/OhyL7+pzBUAxrjFO9pT44nfcUlGE3a/pVVFZ9l/1WwKpuKuZKIAvqrIQ8VO V+BsDV4/hbNVuccnDCp2FqhNihRG46EBuKSlUL/pX96UkboFlpi08DgMAPlHYJ85wwD5FC+u TfK6xt0LVDVNUfY65xDPoIBcG3FmvOSxTRN3/6GyWrKIgXf3bW75Ln6rQ84++nPJQO0ZspgZ zEFEhVsGYjEnieQPFmHKc7hCwlbF/NKggFkPsukqSRkoeMMIbWDQ==
X-Talos-CUID: 9a23:DG01G2Gj3d7ERfi2qmI+02spKNAVdkHy7y3qGU2oUX1neaSaHAo=
X-Talos-MUID: 9a23:N6p+kw+im3o+EhmMWl8FIWGQf+Q4/ar2KRwqrb4Hl5aJGC4oJRS5vB3iFw==
X-IronPort-Anti-Spam-Filtered: true
Received: from aer-iport-nat.cisco.com (HELO aer-core-9.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Apr 2023 06:17:37 +0000
Received: from aer-opgw-3.cisco.com (aer-opgw-3.cisco.com [173.38.212.135]) by aer-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 33D6Hava053498 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Apr 2023 06:17:37 GMT
Received: from mail-co1nam11lp2171.outbound.protection.outlook.com (HELO NAM11-CO1-obe.outbound.protection.outlook.com) ([104.47.56.171]) by aer-opgw-3.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2023 06:17:36 +0000
Received: from mail-co1nam11lp2171.outbound.protection.outlook.com (HELO NAM11-CO1-obe.outbound.protection.outlook.com) ([104.47.56.171]) by aer-opgw-3.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2023 06:17:36 +0000
Received: from mail-co1nam11lp2171.outbound.protection.outlook.com (HELO NAM11-CO1-obe.outbound.protection.outlook.com) ([104.47.56.171]) by aer-opgw-3.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2023 06:17:36 +0000
Authentication-Results: aer-opgw-3.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=fbrockne@cisco.com; dmarc=pass (p=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="5.98,339,1673913600"; d="scan'";a="94702"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N6W5pvjn/W8FNCkH4SdSfemnanzvXQ5z8WkWEBpl28/cT0VdlIogsst6GJWPccm1bK/tFSCHOywEkFaX2oW+UJnsVTO813/da+aUkTAOjKYQpitdoP4Pd/9j2GDsSbOSO8z/E2NoojhvHDqZ9f0t6e0/LFPvz01oiF5MgD/I2bE6zoezBOSjXqEeVHIdReizeOWpqkAmr35FPNWVTOkB556FayKDTHfBdr82nCFiLbj+H7xsfVSyRG4CmOeTcz+PL1x/beED5i0bmamFEShdT7ZlUUD26ReA0qcaLjTPdR/uwISY6VSVrXk839QyhhPxyqXdPzhs/zH3El8kyiu3xw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MKS+oxjiPZ6gQWR1AeEyc/WISCD4hdz9EbieIsUDnac=; b=AOSmN2Uy8OOQk5fMZJvD67N5gPGYVqH9nbd5HFdbljMSFaqsKAkUMQ2G/auQn4ncYa8P1CilLib3sCjhfTP6iBeO4LxesvJTINqR5FxOHdP299nLczKwuKHRhCdj7Xkga4JiU14ZvUlx7yZrBp056sz3/3sJaWgmRMjEGuMMFe+3DnLgRaPRSepDJZ/BTH/qu5ZG9FliMNos/EtmlJ0rQLDTQjY9ZHMYYAuL9pZAXIE+rNepoRJhecHE56fqYjJVOY0hhE5mu1niIkOK7b+4qjzeoH4o26p9vum1jj36WJdjcAKj3VjLJdD5N4J+7CQ8tYIFAl2+W4nVqJejxZvTNA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MKS+oxjiPZ6gQWR1AeEyc/WISCD4hdz9EbieIsUDnac=; b=BqETaPVIuQfrmd2CrPdwltzRs/WsI/hcnND8Xw6I/eLO0rADOhZl+Ry+tFxjmnujLH9ITx3kq3QdDQWrYJk4OwA9BCSUjhLyhBDtVA61j30/cHpBpxdVwCpQ66X75wos9/ZJlYEMN9MKWWRnwbygmKnofsRARIsqjCLHAict1wU=
Received: from MWHPR11MB1311.namprd11.prod.outlook.com (2603:10b6:300:2a::14) by DM6PR11MB4627.namprd11.prod.outlook.com (2603:10b6:5:2a2::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.30; Thu, 13 Apr 2023 06:17:30 +0000
Received: from MWHPR11MB1311.namprd11.prod.outlook.com ([fe80::4893:8718:72a6:4f15]) by MWHPR11MB1311.namprd11.prod.outlook.com ([fe80::4893:8718:72a6:4f15%6]) with mapi id 15.20.6298.030; Thu, 13 Apr 2023 06:17:30 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Sarah Tarrant <starrant@amsl.com>, Martin Duke <martin.h.duke@gmail.com>
CC: Tal Mizrahi <tal.mizrahi.phd@gmail.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "shwetha.bhandari@thoughtspot.com" <shwetha.bhandari@thoughtspot.com>, "daniel.bernier@bell.ca" <daniel.bernier@bell.ca>, "ippm-ads@ietf.org" <ippm-ads@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "tpauly@apple.com" <tpauly@apple.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: [AD] AUTH48: RFC-to-be 9378 <draft-ietf-ippm-ioam-deployment-05> for your review
Thread-Index: AQHZYPEMhpmUnlLCP0iqwJAz5X7J0q8bd4CggAFVLwCAAzSPAIAHbLlAgAB9c4CAAAFdAIAAHF8AgADT9WA=
Date: Thu, 13 Apr 2023 06:17:30 +0000
Message-ID: <MWHPR11MB13117A97DE27560988FCE397DA989@MWHPR11MB1311.namprd11.prod.outlook.com>
References: <20230327211350.435D288A97@rfcpa.amsl.com> <MWHPR11MB1311A5052D16C984013AC85EDA939@MWHPR11MB1311.namprd11.prod.outlook.com> <CABUE3Xn+ihFCOW9-=pdxdgiiEfYH0hgE2vYC9wF=cRqGkSMEsg@mail.gmail.com> <208277D8-B187-4F3A-A111-014868A0512D@amsl.com> <MWHPR11MB1311D291CF4008E212376A8CDA9B9@MWHPR11MB1311.namprd11.prod.outlook.com> <A2FCCE72-97C0-4EA1-84D4-FE749FB5E2D2@amsl.com> <CAM4esxRWEVVybCcOPJCSrvWFR_pajPO-MQZdxbCXbLJigGNjfQ@mail.gmail.com> <98A350E0-DC26-4892-A669-D9D0918A3AFD@amsl.com>
In-Reply-To: <98A350E0-DC26-4892-A669-D9D0918A3AFD@amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MWHPR11MB1311:EE_|DM6PR11MB4627:EE_
x-ms-office365-filtering-correlation-id: c32c10e7-d37e-4275-38d8-08db3be6c2ec
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vU22DeFR4PixHcDEK0RsukT5FjySStLwvVtQ2FyVA0ul8aXe7jg3zXnuAgVCNPDLObWYBIlcCtHAKISqU1PSvoHja2V8VZfpkoebRd7BO/O7Jq5/2n0LzsOdg6uAF1YUaUJ8BCC4AqVc5SYAdIqyFtJF6csIzjpBt4Yg0UBySKREd3wPrFbX3QofX6DUIzGLtKaMH6M/RSFhjTOvlgMVQ9E4sDt4Xl6AvpcpzVh+3QDwpeM1dIGvjpVp7blB9tMB+PwWn7auXnyilue1W3E4szrhc16YarYZCbN4dJGRk9JK7vXV+PtJZMGXRN3v61Fa4ndTllkwKd2gAhsz0gkarUhpX70XXaxQ8IWw8guIBMsePO/jhbalVGx0iJSBrf3Q3XKG5diLZPvxOBPNQt28e/GB27fet15fEJkh/qO6TOHqr/c4a2gFAqRIpCFJG5bpLGCSLp1ejjRJQXPfNRylBcPd4Nm7daWsVPZoJaaGLh8wc3vXPceuvsZRqnGIBclbm/9nciegSq2WAJVYdz5+33X63iaGvulthvuCbn2bVK4obl3zOQM/kEki/p9cQeyvBhKHHT4J+ODAeBnYI88lYitGff5I3a2r+t+dPoKqamLZiWrl+ZR3IdiW3UnSVlSWYfp0RV+TF7mg3XmWJl6ARbrJPMb8W3ugKhusZeC//qEcQZyRRtjAGbdNzg1Fr/RR
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1311.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(136003)(396003)(346002)(376002)(39860400002)(366004)(451199021)(71200400001)(7696005)(966005)(64756008)(66446008)(66476007)(66556008)(66946007)(4326008)(76116006)(19627235002)(110136005)(30864003)(2906002)(7416002)(38070700005)(86362001)(122000001)(41300700001)(33656002)(5660300002)(52536014)(8676002)(8936002)(316002)(38100700002)(478600001)(55016003)(54906003)(53546011)(9686003)(6506007)(26005)(186003)(84970400001)(66899021)(83380400001)(66574015)(2304002)(559001)(579004)(19607625013); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: AappU7wciVkMp5gA27CEn0VD6SEKZWO5tCnnbQhJ0AbCURb0z0xSS8Hao9V8Z38RqEyAWAknzb+C2edtssFgrVetteb+pXXy8y74njJWj5CrAawoAxXxRBh/i8wZHeHhL5yIqF325GhJdZHG5OazeZOz3pThmEkwe7CDeWoJ3d3nFRk9INPLMSd9eAzYWabpcSTxSdr5IVcPnO/SmwHSE6LQSz4vvzkzebysWQcxpKDxwAAmuLqUszAZ/rVkMTimYIEze48m/H1WlxrnaZr/YPu+YdHkz+XtAzsYj9Fg82hmx8xXvh/m/coRtily4qPq8rJIHe0zHT0Ocxq12wC/G2KM8zumW9FVEcq/GEH6UwZXIkb6fYNbOnbQKPtZ9mgK1yMqmTI2DCV0yNmWMgBMd91N5PvS2vCw/v+NURO/EZFv6ayJXzti3i6Nuw5at5MeuMhxBZCAmgDu1Kan4vpRFdGYwn2TwitJMRXRsI2XczCPcr1liCG5tUCZeZNEQB5Gie0DCVaF03ah/OMDaKAl0uK+02oCdhZi3fYbsb0zdJp0jPueAAmQrNfZqlBXZRVvOby23lKChb0AKWWxRZURw249M/XmdM4g4KOETKL7WPKGy/n0jS9a2/MjGlRDWS8GeOFAZvuek7sHUzOZSXCkq1OsD7Qd6kTsEvKR5XeWP6fnFeVZunKc7E2WaE/O+nCAkzNCn7fL+t1dctGp4OG/SjsTDQCvNJRKoB4lEM7CKqbvdgIA/gOeMF/ZaXELtfDVyLf29TpoDI3+aF/TaDzj5IjkMY0nr3qYtLOOt6KawLkb2w1LsUdZAOxryZJClhTW20nGEuxBZDYXouA7swOxVN/VAR3xhObS2XilAWBHQUMxSe0rkup7qmItHxOkwatIuzWgk243U5yaT3j3LgOO3cVfg8SI38rVMAhD4C/nWADCahxTpAFPCNVMoQkD+M9FFYug2HlKrMmtAmYtcOTUeIyVbBCO2AvLe+dz5iit8vMqhp9DLF8y+Leh13vTRtpEED/xwzY+mHj3VF5E363/BNYY/zwTXY8h+XrtMRIhB6h4wQhdxdB/6+etzofM5LFU1r50TeF9W0dL/oPmKjDtIQ5FHuL4OtPSVGZc+ovGWOT1uKH+YDpQ4ahzw0feje8xi1rGAP4bx4GVvYARddtXWTh8QIDqKNIVusJIrSH+mX2tDoHV0PvkQqtFJsxNae0PKVh3FINPiDjCVMhmgClQrJ0zWYMH2jGv4F6ayRnGCh7kKeYPEGfWhRCc6rUbVL0VwM4JwqsUV9RVWV3sjW1ABk+fnMsSqZO0al1Jbemz/bccxaXHnrylFQ4gYmKVeWvcOfnNu/nNgxrZgabDILcwqTyuHRwyUOOW2NoZ/CmqzXfk8aFZv9ZZpQRu3CUzFgea3UXpqsKhzb5SX7TkOohBJgp7xKg//Q0dqUl4bOK1/mUsvUL5Eo2P6x3sTh8cZPNtK+Fako8af9lbTSi122Ks1i07cjWk174phctG8E9DpF5XVefT7YI2W8BoLM/oftKtgLiFOtyNHtQyQkukXM1TLNqCK+z0FNoOl2U/UMOzwp+9OpGst027X3Tw2nlczOIT
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1311.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c32c10e7-d37e-4275-38d8-08db3be6c2ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2023 06:17:30.1305 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yhbRRCpH35brolr9SfNyyppFMKI+wdClcfZGM7KdyD9TVYyv8TfKVGVuk+cz8zBSFQU+4ElFptFYf9+L/0YHhQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4627
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/2yYw8XfJvMAi0ysr6xfdzZfTAqg>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-ietf-ippm-ioam-deployment-05> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2023 06:17:47 -0000
Hi Sarah, Thanks for the changes. The document LGTM - I approve the doc as one of the authors. Cheers, Frank > -----Original Message----- > From: Sarah Tarrant <starrant@amsl.com> > Sent: Wednesday, 12 April 2023 19:38 > To: Martin Duke <martin.h.duke@gmail.com> > Cc: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tal Mizrahi > <tal.mizrahi.phd@gmail.com>; rfc-editor@rfc-editor.org; > shwetha.bhandari@thoughtspot.com; daniel.bernier@bell.ca; ippm- > ads@ietf.org; ippm-chairs@ietf.org; tpauly@apple.com; auth48archive@rfc- > editor.org > Subject: Re: [AD] AUTH48: RFC-to-be 9378 <draft-ietf-ippm-ioam-deployment- > 05> for your review > > Hi Martin, > > We have updated your status to “Approved” at https://www.rfc- > editor.org/auth48/rfc9378. > > We will await approvals from the three remaining authors prior to moving this > document forward in the publication process. > > Thank you. > > RFC Editor/st > > > On Apr 12, 2023, at 10:56 AM, Martin Duke <martin.h.duke@gmail.com> > wrote: > > > > Revised Sec 3 LGTM > > > > On Wed, Apr 12, 2023 at 8:51 AM Sarah Tarrant <starrant@amsl.com> wrote: > > Hi Frank and *Martin, > > > > [*Martin - just a reminder that we are requesting your review/approval > > of the text added to Section 3 as highlighted in the following diff: > > https://www.rfc-editor.org/authors/rfc9378-auth48diff.html.] > > > > Thank you for your reply and guidance. We have updated accordingly. > > > > Please review the files carefully as we do not make changes after publication. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9378.txt > > https://www.rfc-editor.org/authors/rfc9378.pdf > > https://www.rfc-editor.org/authors/rfc9378.html > > https://www.rfc-editor.org/authors/rfc9378.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9378-diff.html (comprehensive diff) > > https://www.rfc-editor.org/authors/rfc9378-auth48diff.html (AUTH48 > changes only) > > https://www.rfc-editor.org/authors/rfc9378-lastdiff.html (last to > > current version only) > > > > Please contact us with any further updates/questions/comments you may > have. > > > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9378 > > > > Thank you. > > > > RFC Editor/st > > > > > On Apr 12, 2023, at 3:44 AM, Frank Brockners (fbrockne) > <fbrockne@cisco.com> wrote: > > > > > > Hi Sarah, > > > > > > Thanks for the updates. Please see inline.. ("..FB") > > > > > >> -----Original Message----- > > >> From: Sarah Tarrant <starrant@amsl.com> > > >> Sent: Friday, 7 April 2023 17:00 > > >> To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>; Frank Brockners > > >> (fbrockne) <fbrockne@cisco.com>; martin.h.duke@gmail.com > > >> Cc: rfc-editor@rfc-editor.org; shwetha.bhandari@thoughtspot.com; > > >> daniel.bernier@bell.ca; ippm-ads@ietf.org; ippm-chairs@ietf.org; > > >> tpauly@apple.com; auth48archive@rfc-editor.org > > >> Subject: Re: [AD] AUTH48: RFC-to-be 9378 > > >> <draft-ietf-ippm-ioam-deployment- > > >> 05> for your review > > >> > > >> Hi Frank and Tal (and *Martin), > > >> > > >> [*Martin - please review and approve the changes highlighted at the > > >> beginning of Section 3 in the AUTH48 diff file below.] > > >> > > >> Thank you for your replies and guidance. We have marked Tal as > > >> “approved" at the AUTH48 status page (see below). We will assume > > >> Tal’s assent to any further changes provided by the coauthors unless we > hear otherwise at that time. > > >> > > >> Please review the following further questions that arose while we > > >> implemented the requested updates. We will await your responses to > > >> these questions prior to moving the document forward in the publication > process. > > >> > > >> 1) Regarding question 5, please let us know if any further updates > > >> were necessary regarding point b or if you would like to keep the text as is. > > > > > > ...FB: See below for a minor suggestion. > > > > > >> > > >>>>> 5) <!-- [rfced] We had two questions related to the first two subpoints > > >>>>> in the list in Section 4: > > >>>>> > > >>>>> a) To make the two nested points parallel, should the second > > >>>>> point be rewritten > > >>>>> ("Operations/Troubleshooting: Understand" updated to "With > > >>>>> regard to operations and troubleshooting, understand...")? Or > > >>>>> should the first nested point have a similar introduction to the second? > > >>>>> Please let us know if our suggestion below is a viable solution > > >>>>> or if there is another way to rephrase. > > >>>>> > > >>>>> b) Also, please clarify the two instances of "Understand". Who > > >>>>> is understanding the different paths? Or is there another way > > >>>>> to clarify > > >> "Understand"? > > >>>>> > > >>>>> Original: > > >>>>> Potential uses of IOAM per-hop tracing include: > > >>>>> > > >>>>> - Understand the different paths different packets traverse > > >>>>> between an IOAM encapsulating and an IOAM decapsulating node in > > >>>>> a network that uses load balancing such as Equal Cost Multi- > > >>>>> Path (ECMP). This information could be used to tune the > > >>>>> algorithm for ECMP for optimized network resource usage. > > >>>>> > > >>>>> - Operations/Troubleshooting: Understand which path a particular > > >>>>> packet or set of packets take as well as what amount of jitter > > >>>>> and delay different IOAM nodes in the path contribute to the > > >>>>> overall delay and jitter between the IOAM encapsulating node > > >>>>> and the IOAM decapsulating node. > > >>>>> > > >>>>> Perhaps: > > >>>>> Potential uses of IOAM per-hop tracing include: > > >>>>> > > >>>>> - Understanding the different paths different packets traverse > > >>>>> between an IOAM encapsulating and an IOAM decapsulating node in > > >>>>> a network that uses load-balancing such as Equal Cost Multi- > > >>>>> Path (ECMP). This information could be used to tune the > > >>>>> algorithm for ECMP for optimized network resource usage. > > >>>>> > > >>>>> - With regard to operations and troubleshooting, understanding > which > > >>>>> path a particular packet or set of packets take as well as what > > >>>>> amount of jitter and delay different IOAM nodes in the path > > >>>>> contribute to the overall delay and jitter between the IOAM > > >>>>> encapsulating node and the IOAM decapsulating node. > > >>>>> --> > > >>>> > > >>>> ...FB: I like your proposal. > > > > > > ...FB: IMHO it would be good to mention "IOAM encapsulating node" in the > sentence below, rather than just "IOAM encapsulating". But this is just my > "feeling" as a non-native English speaker. > > > > > > CURRENT: > > > * Understanding the different paths that different packets > > > traverse between an IOAM encapsulating and an IOAM > > > decapsulating node in a network that uses load balancing, such > > > as Equal Cost Multi-Path (ECMP). This information could be > > > used to tune the algorithm for ECMP for optimized network > > > resource usage. > > > > > > NEW: > > > * Understanding the different paths that different packets > > > traverse between an IOAM encapsulating node and an IOAM > > > decapsulating node in a network that uses load balancing, such > > > as Equal Cost Multi-Path (ECMP). This information could be > > > used to tune the algorithm for ECMP for optimized network > > > resource usage. > > > > > >> > > >> > > >> 2) Regarding question 6, where Frank wrote: > > >> > > >>>> NEW: > > >>>> > > >>>> * Generic data, that is format-free information, where the syntax and > > >>>> semantics of the information are defined by the operator in a specific > > >>>> deployment. > > >> > > >> please note that we further updated to use “Generic data, which is > > >> format-free information, where…” as we assume the intention is to > > >> give further information on the generic data (not to contrast it with generic > data that is not format-free). > > >> Please let us know any objections. > > > > > > ...FB: ACK. The change to "which" makes sense. > > > > > >> > > >> > > >> 3) When making terminology updates, we wanted to clarify the following: > > >> > > >> a) Please confirm that the “Perhaps” text below is an *example* of > > >> a desired update (similar text occurs elsewhere). > > >> > > >> Original: > > >> The incremental IOAM-Trace-Option-Type eliminates the need for the > > >> IOAM transit nodes to read the full array in the Trace-Option-Type > > >> and allows packets to grow to the size of the MTU of the IOAM domain. > > >> > > >> Current: > > >> The incremental IOAM Trace > > >> Option-Type eliminates the need for the IOAM transit nodes to read > > >> the full array in the Trace Option-Type and allows packets to grow > > >> to the size of the MTU of the IOAM-Domain. > > >> > > >> Perhaps: > > >> The IOAM Incremental Trace > > >> Option-Type eliminates the need for the IOAM transit nodes to read > > >> the full array in the Trace Option-Type and allows packets to grow > > >> to the size of the MTU of the IOAM-Domain. > > > > > > ...FB: Agreed. Your suggestion is more accurate. > > > > > >> > > >> b) We were uncertain about the updates to “Active flag” per the > > >> author > > >> response: > > >> > > >>> Original: > > >>> IOAM active mode flag > > >>> Active flag > > >>> > > >>> Perhaps: > > >>> Active flag (per RFC 9322) > > >> > > >> ...FB: Agreed. > > >> > > >>> > > >>> See also IOAM Active Mode. > > >> > > >> > > >> Should the title of Section 7.6 be updated as follows? > > >> > > >> Current: > > >> IOAM Active Mode > > >> > > >> Perhaps: > > >> Active Flag > > > > > > ...FB: Agreed. Keeping things consistent with RFC 9322 is appreciated. > > > > > > ...FB: In order to keep things consistent in the document, IMHO it > > > would make sense to also change4 > > > > > > CURRENT: > > > > > > 7.5. IOAM Loopback > > > > > > NEW: > > > > > > 7.5. Loopback flag > > > > > >> > > >> See also: > > >> > > >> Current: > > >> Example use cases for IOAM Active Mode include: > > >> > > >> Perhaps: > > >> Example use cases for the Active flag include: > > > > > > ...FB: Agreed. > > > > > >> > > >> > > >> We have updated the document with all the other changes as > > >> requested. Please review these updates carefully as we do not make > > >> changes once the document is published as an RFC. We will > > >> approvals from each coauthor prior to moving the document forward in the > publication process. > > > > > > > > > ...FB: When reading through the document, I found another minor > inconsistency in language in section 10 ("Direct Exporting mode" vs. "Direct > Exporting"). IMHO it would be good to avoid "mode" here as well and just refer > to "Direct Exporting" > > > > > > CURRENT: > > > > > > IOAM data can be subject to eavesdropping. Although the > > > confidentiality of the user data is not at risk in this context, the > > > IOAM data elements can be used for network reconnaissance, allowing > > > attackers to collect information about network paths, performance, > > > queue states, buffer occupancy, and other information. Recon is an > > > improbable security threat in an IOAM deployment that is within a > > > confined physical domain. However, in deployments that are not > > > confined to a single LAN but span multiple interconnected sites (for > > > example, using an overlay network), the inter-site links are expected > > > to be secured (e.g., by IPsec) in order to avoid external > > > eavesdropping and introduction of malicious or false data. Another > > > possible mitigation approach is to use the "Direct Exporting" mode > > > [RFC9326]. In this case, the IOAM-related trace information would > > > not be available in the customer data packets but would trigger the > > > exporting of (secured) packet-related IOAM information at every node. > > > IOAM data export and securing IOAM data export is outside the scope > > > of this document. > > > > > > [...] > > > > > > Notably, IOAM is expected to be deployed in limited network domains > > > [RFC8799], thus, confining the potential attack vectors within the > > > limited domain. Indeed, in order to limit the scope of threats > > > within the current network domain, the network operator is expected > > > to enforce policies that prevent IOAM traffic from leaking outside > > > the IOAM-Domain and prevent an attacker from introducing malicious or > > > false IOAM data to be processed and used within the IOAM-Domain. > > > IOAM data leakage could lead to privacy issues. Consider an IOAM > > > encapsulating node that is a home gateway in an operator's network. > > > A home gateway is often identified with an individual. Revealing > > > IOAM data, such as "IOAM node identifier" or geolocation information > > > outside of the limited domain, could be harmful for that user. Note > > > that the Direct Exporting mode [RFC9326] can mitigate the potential > > > threat of IOAM data leaking through data packets. > > > > > > NEW: > > > IOAM data can be subject to eavesdropping. Although the > > > confidentiality of the user data is not at risk in this context, the > > > IOAM data elements can be used for network reconnaissance, allowing > > > attackers to collect information about network paths, performance, > > > queue states, buffer occupancy, and other information. Recon is an > > > improbable security threat in an IOAM deployment that is within a > > > confined physical domain. However, in deployments that are not > > > confined to a single LAN but span multiple interconnected sites (for > > > example, using an overlay network), the inter-site links are expected > > > to be secured (e.g., by IPsec) in order to avoid external > > > eavesdropping and introduction of malicious or false data. Another > > > possible mitigation approach is to use "Direct Exporting" > > > [RFC9326]. In this case, the IOAM-related trace information would > > > not be available in the customer data packets but would trigger the > > > exporting of (secured) packet-related IOAM information at every node. > > > IOAM data export and securing IOAM data export is outside the scope > > > of this document. > > > > > > [...] > > > > > > Notably, IOAM is expected to be deployed in limited network domains > > > [RFC8799], thus, confining the potential attack vectors within the > > > limited domain. Indeed, in order to limit the scope of threats > > > within the current network domain, the network operator is expected > > > to enforce policies that prevent IOAM traffic from leaking outside > > > the IOAM-Domain and prevent an attacker from introducing malicious or > > > false IOAM data to be processed and used within the IOAM-Domain. > > > IOAM data leakage could lead to privacy issues. Consider an IOAM > > > encapsulating node that is a home gateway in an operator's network. > > > A home gateway is often identified with an individual. Revealing > > > IOAM data, such as "IOAM node identifier" or geolocation information > > > outside of the limited domain, could be harmful for that user. Note > > > that Direct Exporting [RFC9326] can mitigate the potential > > > threat of IOAM data leaking through data packets. > > > > > > Cheers, Frank > > > > > > > > >> > > >> The files have been posted here (please refresh): > > >> https://www.rfc-editor.org/authors/rfc9378.txt > > >> https://www.rfc-editor.org/authors/rfc9378.pdf > > >> https://www.rfc-editor.org/authors/rfc9378.html > > >> https://www.rfc-editor.org/authors/rfc9378.xml > > >> > > >> The relevant diff files have been posted here (please refresh): > > >> https://www.rfc-editor.org/authors/rfc9378-diff.html (comprehensive > > >> diff) https://www.rfc-editor.org/authors/rfc9378-rfcdiff.html > > >> (comprehensive > > >> rfcdiff) > > >> https://www.rfc-editor.org/authors/rfc9378-auth48diff.html (AUTH48 > > >> changes only) > > >> > > >> The AUTH48 status page is viewable at: > > >> https://www.rfc-editor.org/auth48/rfc9378 > > >> > > >> Thank you. > > >> > > >> RFC Editor/st > > >>> On Apr 5, 2023, at 9:02 AM, Tal Mizrahi <tal.mizrahi.phd@gmail.com> > wrote: > > >>> > > >>> Dear RFC Editorial Team, > > >>> > > >>> I agree with Frank's comments. > > >>> I approve. > > >>> > > >>> Thanks, > > >>> Tal. > > >>> > > >>> On Tue, Apr 4, 2023 at 9:26 PM Frank Brockners (fbrockne) > > >>> <fbrockne@cisco.com> wrote: > > >>>> > > >>>> Dear Sarah, RFC-Editor team, > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> > > >>>>> Sent: Monday, 27 March 2023 23:14 > > >>>>> To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; > > >>>>> shwetha.bhandari@thoughtspot.com; daniel.bernier@bell.ca; > > >>>>> tal.mizrahi.phd@gmail.com > > >>>>> Cc: rfc-editor@rfc-editor.org; ippm-ads@ietf.org; > > >>>>> ippm-chairs@ietf.org; tpauly@apple.com; martin.h.duke@gmail.com; > > >>>>> auth48archive@rfc-editor.org > > >>>>> Subject: Re: AUTH48: RFC-to-be 9378 > > >>>>> <draft-ietf-ippm-ioam-deployment-05> > > >>>>> for your review > > >>>>> > > >>>>> Authors, > > >>>>> > > >>>>> While reviewing this document during AUTH48, please resolve (as > > >>>>> necessary) the following questions, which are also in the XML file. > > >>>>> > > >>>>> 1) <!-- [rfced] Please note that the title of the document has > > >>>>> been updated as follows to more similarly match related recently > published RFCs. > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> In-situ OAM Deployment > > >>>>> > > >>>>> Current: > > >>>>> In Situ Operations, Administration, and Maintenance (IOAM) > > >>>>> Deployment > > >>>>> --> > > >>>> > > >>>> ...FB: ACK. > > >>>> > > >>>>> > > >>>>> > > >>>>> 2) <!-- [rfced] We suggest updating the following text for the ease of > > >>>>> the reader. Please let us know any objections. > > >>>>> > > >>>>> Original: > > >>>>> IOAM mechanisms can be > > >>>>> leveraged where mechanisms using e.g., ICMP do not apply or do > > >>>>> not offer the desired results, such as proving that a certain > > >>>>> traffic flow takes a pre-defined path, SLA verification for the > > >>>>> live data traffic, detailed statistics on traffic distribution > > >>>>> paths in networks that distribute traffic across multiple > > >>>>> paths, or scenarios in which probe traffic is potentially > > >>>>> handled differently from regular data traffic by the network devices. > > >>>>> > > >>>>> Perhaps: > > >>>>> IOAM mechanisms can be > > >>>>> leveraged where mechanisms using, e.g., ICMP do not apply or do > > >>>>> not offer the desired results. These results could include: > > >>>>> > > >>>>> * proving that a certain traffic flow takes a predefined > > >>>>> path, > > >>>>> > > >>>>> * verifying the Service Level Agreement (SLA) for the live data > > >>>>> traffic, > > >>>>> > > >>>>> * providing detailed statistics on traffic distribution paths in > > >>>>> networks that distribute traffic across multiple paths, > > >>>>> or > > >>>>> > > >>>>> * providing scenarios in which probe traffic is potentially > > >>>>> handled differently from regular data traffic by the network > > >>>>> devices. > > >>>>> --> > > >>>> > > >>>> ...FB: Making this long winded sentence more readable is very > > >>>> worthwhile. In > > >> your proposal, the term "result" could be misunderstood though. > > >>>> How about the following: > > >>>> > > >>>> NEW: > > >>>> > > >>>> IOAM mechanisms can be leveraged in situations where mechanisms > > >>>> using, e.g., ICMP does not apply or does not offer the desired > > >>>> results. These situations could include: > > >>>> > > >>>> * proving that a certain traffic flow takes a predefined > > >>>> path, > > >>>> > > >>>> * verifying the Service Level Agreement (SLA) for the live data > > >>>> traffic, > > >>>> > > >>>> * providing detailed statistics on traffic distribution paths in > > >>>> networks that distribute traffic across multiple paths, or > > >>>> > > >>>> * providing scenarios in which probe traffic is potentially > > >>>> handled differently from regular data traffic by the network > > >>>> devices. > > >>>> > > >>>> > > >>>>> > > >>>>> > > >>>>> 3) <!--[rfced] We note a lot of similarities in the text of > > >>>>> Section > > >>>>> 3 with the text that appears in Section 4.2 of RFC 9197. > > >>>>> However, there is no citation to that document in Section 3. > > >>>>> Please review and let us know if a citation should be added, any > > >>>>> text should be updated, or if the reader should simply be > > >>>>> pointed to Section 4.2 of RFC 9197 for certain info.--> > > >>>> > > >>>> ...FB: Good point. Given that (a) the deployment document is a > > >>>> bit more > > >> recent than RFC 9197, (b) a partial repeat of definitions helps the > > >> reader and (c) the IESG had comments and text suggestions on the > > >> section which led to revised text, IMHO it would be better to keep the > section in place rather than remove it. > > >> That said, what would make sense is to add a paragraph up front > > >> which states the reference to RFC 9197. E.g. > > >>>> > > >>>> OLD: > > >>>> > > >>>> 3. IOAM Deployment: Domains And Nodes > > >>>> > > >>>> IOAM is focused on "limited domains" as defined in [RFC8799]. > > >>>> IOAM is not targeted for a deployment on the global Internet. ... > > >>>> > > >>>> NEW: > > >>>> > > >>>> 3. IOAM Deployment: Domains And Nodes > > >>>> > > >>>> RFC 9197 defines the scope of IOAM as well as the different > > >>>> types of IOAM nodes. For improved readability, this section > > >>>> provides a brief overview of where IOAM applies, along with > > >>>> explaining the main roles of nodes that employ IOAM. > > >>>> Please refer to RFC 9197 for further details. > > >>>> > > >>>> IOAM is focused on "limited domains" as defined in [RFC8799]. > > >>>> IOAM is not targeted for a deployment on the global Internet. ... > > >>>> > > >>>>> > > >>>>> > > >>>>> 4) <!-- [rfced] Does this instance of "/" indicate "and" or "or"? > > >>>>> Please let us know how we may update for clarity. > > >>>>> > > >>>>> Original: > > >>>>> For example, an IOAM-domain can include an enterprise campus > > >>>>> using physical connections between devices or an overlay > > >>>>> network using virtual connections / tunnels for connectivity between > said devices. > > >>>>> > > >>>>> Perhaps: > > >>>>> a) > > >>>>> For example, an IOAM-Domain can include an enterprise campus > > >>>>> using physical connections between devices or an overlay > > >>>>> network using virtual connections and tunnels for connectivity between > said devices. > > >>>>> > > >>>>> b) > > >>>>> For example, an IOAM-Domain can include an enterprise campus > > >>>>> using physical connections between devices or an overlay > > >>>>> network using virtual connections or tunnels for connectivity between > said devices. > > >>>>> --> > > >>>> > > >>>> ...FB: It is option b). I.e., > > >>>> > > >>>> NEW: > > >>>> > > >>>> For example, an IOAM-Domain can include an enterprise campus using > > >>>> physical connections between devices or an overlay network using > > >>>> virtual connections or tunnels for connectivity between said devices. > > >>>> > > >>>> > > >>>>> > > >>>>> > > >>>>> 5) <!-- [rfced] We had two questions related to the first two subpoints > > >>>>> in the list in Section 4: > > >>>>> > > >>>>> a) To make the two nested points parallel, should the second > > >>>>> point be rewritten > > >>>>> ("Operations/Troubleshooting: Understand" updated to "With > > >>>>> regard to operations and troubleshooting, understand...")? Or > > >>>>> should the first nested point have a similar introduction to the second? > > >>>>> Please let us know if our suggestion below is a viable solution > > >>>>> or if there is another way to rephrase. > > >>>>> > > >>>>> b) Also, please clarify the two instances of "Understand". Who > > >>>>> is understanding the different paths? Or is there another way > > >>>>> to clarify > > >> "Understand"? > > >>>>> > > >>>>> Original: > > >>>>> Potential uses of IOAM per-hop tracing include: > > >>>>> > > >>>>> - Understand the different paths different packets traverse > > >>>>> between an IOAM encapsulating and an IOAM decapsulating node > in > > >>>>> a network that uses load balancing such as Equal Cost Multi- > > >>>>> Path (ECMP). This information could be used to tune the > > >>>>> algorithm for ECMP for optimized network resource usage. > > >>>>> > > >>>>> - Operations/Troubleshooting: Understand which path a particular > > >>>>> packet or set of packets take as well as what amount of jitter > > >>>>> and delay different IOAM nodes in the path contribute to the > > >>>>> overall delay and jitter between the IOAM encapsulating node > > >>>>> and the IOAM decapsulating node. > > >>>>> > > >>>>> Perhaps: > > >>>>> Potential uses of IOAM per-hop tracing include: > > >>>>> > > >>>>> - Understanding the different paths different packets traverse > > >>>>> between an IOAM encapsulating and an IOAM decapsulating node > in > > >>>>> a network that uses load-balancing such as Equal Cost Multi- > > >>>>> Path (ECMP). This information could be used to tune the > > >>>>> algorithm for ECMP for optimized network resource usage. > > >>>>> > > >>>>> - With regard to operations and troubleshooting, understanding > which > > >>>>> path a particular packet or set of packets take as well as what > > >>>>> amount of jitter and delay different IOAM nodes in the path > > >>>>> contribute to the overall delay and jitter between the IOAM > > >>>>> encapsulating node and the IOAM decapsulating node. > > >>>>> --> > > >>>> > > >>>> ...FB: I like your proposal. > > >>>> > > >>>>> > > >>>>> > > >>>>> 6) <!-- [rfced] To make this list parallel, may we update "Generic data: > > >>>>> Format-free information where..." to "Generic data, such as > > >>>>> format-free information, where..."? Or would you like the list to > > >>>>> be more of a definition list where each point has a term and then > > >>>>> a definition list? Please let us know how we may update. > > >>>>> > > >>>>> Original: > > >>>>> * Generic data: Format-free information where syntax and semantic of > > >>>>> the information is defined by the operator in a specific > > >>>>> deployment. For a specific IOAM-Namespace, all IOAM nodes should > > >>>>> interpret the generic data the same way. Examples for generic > > >>>>> IOAM data include geolocation information (location of the node at > > >>>>> the time the packet was processed), buffer queue fill level or > > >>>>> cache fill level at the time the packet was processed, or even a > > >>>>> battery charge level. > > >>>>> > > >>>>> Perhaps: > > >>>>> * Generic data, such as format-free information, where the syntax and > > >>>>> semantics of the information are defined by the operator in a specific > > >>>>> deployment. For a specific IOAM-Namespace, all IOAM nodes should > > >>>>> interpret the generic data the same way. Examples for generic > > >>>>> IOAM data include geolocation information (location of the node at > > >>>>> the time the packet was processed), bufferqueue fill level or > > >>>>> cache fill level at the time the packet was processed, or even a > > >>>>> battery charge level. > > >>>>> --> > > >>>> > > >>>> ...FB: Generic data _is_ format-free in case of IOAM. "such as" > > >>>> could be read > > >> as "format-free" information is only an example. How about: > > >>>> > > >>>> NEW: > > >>>> > > >>>> * Generic data, that is format-free information, where the syntax and > > >>>> semantics of the information are defined by the operator in a specific > > >>>> deployment. For a specific IOAM-Namespace, all IOAM nodes should > > >>>> interpret the generic data the same way. Examples for generic > > >>>> IOAM data include geolocation information (location of the node at > > >>>> the time the packet was processed), bufferqueue fill level or > > >>>> cache fill level at the time the packet was processed, or even a > > >>>> battery charge level. > > >>>> > > >>>>> > > >>>>> > > >>>>> 7) <!--[rfced] The following text seems to be taken from RFC 9197. May > > >>>>> we update the capping scheme to match? Note that we will update > > >>>>> s/consist/consists regardless (which seems to be an error in > > >>>>> RFC 9197). > > >>>>> > > >>>>> RFC 9197: > > >>>>> The IOAM Proof of Transit Option-Type consist of a fixed-size > > >>>>> "IOAM Proof of Transit Option header" and "IOAM Proof of Transit > > >>>>> Option data > > >>>>> fields": > > >>>>> > > >>>>> This document: > > >>>>> The IOAM Proof of Transit Option-Type consist of a fixed size > > >>>>> "IOAM proof of transit option header" and "IOAM proof of transit > > >>>>> option data > > >> fields". > > >>>>> > > >>>>> Perhaps: > > >>>>> The IOAM Proof of Transit Option-Type consists of a fixed-size > > >>>>> "IOAM Proof of Transit Option header" and "IOAM Proof of Transit > > >>>>> Option data > > >> fields." > > >>>>> --> > > >>>> > > >>>> ...FB: Your suggestion makes sense. > > >>>> > > >>>>> > > >>>>> > > >>>>> 8) <!--[rfced] We had a question about the citation in this text: > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> ... IOAM loopback mode. For a definition of IOAM Namespaces and > > >>>>> IOAM layering, please refer to [RFC9197]. IOAM loopback mode is > > >>>>> defined in [RFC9322]. > > >>>>> > > >>>>> We note that RFC 9322 never actually uses the term "mode". > > >>>>> Please review and let us know if any updates to the following text are > necessary. > > >>>>> > > >>>> ...FB: Rather than talk about "IOAM loopback mode" we should > > >>>> simply say > > >> "IOAM loopback". > > >>>> How about... > > >>>> > > >>>> NEW: > > >>>> > > >>>> 7. IOAM Deployment Considerations > > >>>> > > >>>> This section describes several concepts of IOAM, and provides > > >>>> considerations that need to be taken to account when implementing > > >>>> IOAM in a network domain. This includes concepts like IOAM > > >>>> Namespaces, IOAM Layering, traffic-sets that IOAM is applied to > > >>>> and IOAM Loopback. For a definition of IOAM Namespaces and IOAM > > >>>> layering, please refer to [RFC9197]. IOAM Loopback is defined > > >>>> in [RFC9322]. > > >>>> > > >>>> > > >>>>> > > >>>>> --> > > >>>>> > > >>>>> > > >>>>> 9) <!-- [rfced] We had the following queries related to terminology use > > >>>>> throughout the document: > > >>>>> > > >>>>> a) The following terminology appears to be used inconsistently. > > >>>>> May we update as suggested below for consistency with past RFCs? > > >>>>> > > >>>>> Original: > > >>>>> Direct export > > >>>>> Direct Export > > >>>>> > > >>>>> Perhaps: > > >>>>> Direct Export (based on RFC 9326) > > >>>> > > >>>> ...FB: Agreed. > > >>>> > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> Incremental Trace-Option-Type > > >>>>> incremental Trace Option-Type > > >>>>> Incremental Trace-Option > > >>>>> Incremental Trace Option-Type > > >>>>> "Incremental" Trace-Option-Type > > >>>>> > > >>>>> Perhaps: > > >>>>> Incremental Trace Option-Type (based on RFC 9197) > > >>>> > > >>>> ...FB: Agreed. > > >>>> > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> IOAM Layering > > >>>>> IOAM layering > > >>>>> > > >>>>> Perhaps: > > >>>>> IOAM Layering (based on RFC 9197) > > >>>> > > >>>> ...FB: Agreed. > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> IOAM Loopback > > >>>>> IOAM loopback > > >>>>> > > >>>>> Perhaps: > > >>>>> ? - RFC 9322 uses IOAM Loopback only once, then we see "IOAM > > >>>>> looped- > > >> back" > > >>>> > > >>>> ...FB: See above. Let's standardize on "IOAM Loopback". > > >>>> > > >>>>> > > >>>>> Original: > > >>>>> IOAM active mode flag > > >>>>> Active flag > > >>>>> > > >>>>> Perhaps: > > >>>>> Active flag (per RFC 9322) > > >>>> > > >>>> ...FB: Agreed. > > >>>> > > >>>>> > > >>>>> See also IOAM Active Mode. > > >>>>> > > >>>>> Original: > > >>>>> loopback flag > > >>>>> > > >>>>> Perhaps: > > >>>>> Loopback flag (per RFC 9322) > > >>>> > > >>>> ...FB: Agreed. > > >>>> > > >>>>> > > >>>>> Original: > > >>>>> IOAM-Namespace > > >>>>> IOAM Namespace > > >>>>> > > >>>>> Perhaps: > > >>>>> IOAM-Namespace (based on RFCs 9197 and 9322) > > >>>> > > >>>> ...FB: Agreed. > > >>>> > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> IOAM-Option-Type > > >>>>> IOAM Option-Type > > >>>>> > > >>>>> Perhaps: > > >>>>> IOAM Option-Type (based on RFC 9197 and 9326) > > >>>> > > >>>> ...FB: Agreed. > > >>>> > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> IOAM-Trace-Option-Type > > >>>>> IOAM Trace Option Type > > >>>>> IOAM Trace Option-Type > > >>>>> > > >>>>> Perhaps: > > >>>>> IOAM Trace Option-Type (based on RFC 9197) > > >>>> > > >>>> ...FB: Agreed. > > >>>> > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> Pre-allocated Trace-Option-Type > > >>>>> pre-allocated Option-Type > > >>>>> Pre-allocated Trace-Option > > >>>>> "Pre-allocated" Trace-Option-Type > > >>>>> > > >>>>> > > >>>>> Perhaps: > > >>>>> Pre-allocated Trace Option-Type (based on RFC 9197) > > >>>> > > >>>> ...FB: Agreed. > > >>>> > > >>>>> > > >>>>> > > >>>>> Original: > > >>>>> Trace-Option-Type > > >>>>> Trace Option-Type > > >>>>> trace Option-Type > > >>>>> > > >>>>> Perhaps: > > >>>>> Trace Option-Type (based on RFC 9197) > > >>>>> > > >>>>> Relating to the two entries above, see also: > > >>>>> The Option-Types of incremental tracing and pre-allocated > > >>>>> tracing are defined in [RFC9197]. > > >>>> > > >>>> ...FB: Agreed. > > >>>>> > > >>>>> > > >>>>> b) We have updated "Edge to Edge" and "Edge-to-edge" to "Edge-to- > Edge" > > >>>>> per RFC 9197. May we update all subsequent instances to "E2E" > > >>>>> when not in quotes? > > >>>> > > >>>> ...FB: Makes sense. > > >>>> > > >>>>> > > >>>>> c) FYI, we have updated to use the following forms (see > > >>>>> capitalization/hyphenation/etc.) of various terms for > > >>>>> consistency with recent RFCs on the topic. Please let us know of any > objections. > > >>>>> > > >>>>> Hop-by-Hop (per RFC 9326) > > >>>>> IOAM-Domain (per feedback on RFC-to-be 9359) Proof of Transit > > >>>>> (per feedback on RFC-to-be 9359) IOAM encapsulating node, IOAM > > >>>>> decapsulating node, IOAM transit node > > >>>>> --> > > >>>> > > >>>> ...FB: ACK. > > >>>> > > >>>>> > > >>>>> > > >>>>> 10) <!-- [rfced] Please review the "Inclusive Language" portion of the > > >>>>> online Style Guide > > >>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > >>>>> and let us know if any changes are needed. Note that our script > > >>>>> did not flag any words in particular, but this should still be > > >>>>> reviewed as a best practice. > > >>>>> --> > > >>>> > > >>>> ...FB: Thanks for the note. I'm also not aware of any challenges > > >>>> wrt/ non- > > >> inclusive language with the current text. > > >>>> I don't see a need for further changes. > > >>>> > > >>>> THANKS A LOT for your suggestions, review and help. > > >>>> > > >>>> Cheers, Frank > > >>>>> > > >>>>> > > >>>>> Thank you. > > >>>>> > > >>>>> RFC Editor/st/mf > > >>>>> > > >>>>> *****IMPORTANT***** > > >>>>> > > >>>>> Updated 2023/03/27 > > >>>>> > > >>>>> RFC Author(s): > > >>>>> -------------- > > >>>>> > > >>>>> Instructions for Completing AUTH48 > > >>>>> > > >>>>> Your document has now entered AUTH48. Once it has been reviewed > > >>>>> and approved by you and all coauthors, it will be published as an RFC. > > >>>>> If an author is no longer available, there are several remedies > > >>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > >>>>> > > >>>>> You and you coauthors are responsible for engaging other parties > > >>>>> (e.g., Contributors or Working Group) as necessary before > > >>>>> providing your > > >> approval. > > >>>>> > > >>>>> Planning your review > > >>>>> --------------------- > > >>>>> > > >>>>> Please review the following aspects of your document: > > >>>>> > > >>>>> * RFC Editor questions > > >>>>> > > >>>>> Please review and resolve any questions raised by the RFC > > >>>>> Editor that have been included in the XML file as comments > > >>>>> marked as > > >>>>> follows: > > >>>>> > > >>>>> <!-- [rfced] ... --> > > >>>>> > > >>>>> These questions will also be sent in a subsequent email. > > >>>>> > > >>>>> * Changes submitted by coauthors > > >>>>> > > >>>>> Please ensure that you review any changes submitted by your > > >>>>> coauthors. We assume that if you do not speak up that you > > >>>>> agree to changes submitted by your coauthors. > > >>>>> > > >>>>> * Content > > >>>>> > > >>>>> Please review the full content of the document, as this cannot > > >>>>> change once the RFC is published. Please pay particular attention to: > > >>>>> - IANA considerations updates (if applicable) > > >>>>> - contact information > > >>>>> - references > > >>>>> > > >>>>> * Copyright notices and legends > > >>>>> > > >>>>> Please review the copyright notice and legends as defined in > > >>>>> RFC 5378 and the Trust Legal Provisions (TLP – > > >>>>> https://trustee.ietf.org/license-info/). > > >>>>> > > >>>>> * Semantic markup > > >>>>> > > >>>>> Please review the markup in the XML file to ensure that > > >>>>> elements of content are correctly tagged. For example, ensure > > >>>>> that <sourcecode> and <artwork> are set correctly. See details > > >>>>> at <https://authors.ietf.org/rfcxml-vocabulary>. > > >>>>> > > >>>>> * Formatted output > > >>>>> > > >>>>> Please review the PDF, HTML, and TXT files to ensure that the > > >>>>> formatted output, as generated from the markup in the XML file, > > >>>>> is reasonable. Please note that the TXT will have formatting > > >>>>> limitations compared to the PDF and HTML. > > >>>>> > > >>>>> > > >>>>> Submitting changes > > >>>>> ------------------ > > >>>>> > > >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ > > >>>>> as all the parties CCed on this message need to see your > > >>>>> changes. The parties > > >>>>> include: > > >>>>> > > >>>>> * your coauthors > > >>>>> > > >>>>> * rfc-editor@rfc-editor.org (the RPC team) > > >>>>> > > >>>>> * other document participants, depending on the stream (e.g., > > >>>>> IETF Stream participants are your working group chairs, the > > >>>>> responsible ADs, and the document shepherd). > > >>>>> > > >>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list > > >>>>> to preserve AUTH48 conversations; it is not an active discussion > > >>>>> list: > > >>>>> > > >>>>> * More info: > > >>>>> > > >>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- > > >>>>> 4Q9l2USxIAe6P8O4Zc > > >>>>> > > >>>>> * The archive itself: > > >>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > > >>>>> > > >>>>> * Note: If only absolutely necessary, you may temporarily opt out > > >>>>> of the archiving of messages (e.g., to discuss a sensitive matter). > > >>>>> If needed, please add a note at the top of the message that you > > >>>>> have dropped the address. When the discussion is concluded, > > >>>>> auth48archive@rfc-editor.org will be re-added to the CC list and > > >>>>> its addition will be noted at the top of the message. > > >>>>> > > >>>>> You may submit your changes in one of two ways: > > >>>>> > > >>>>> An update to the provided XML file — OR — An explicit list of > > >>>>> changes in this format > > >>>>> > > >>>>> Section # (or indicate Global) > > >>>>> > > >>>>> OLD: > > >>>>> old text > > >>>>> > > >>>>> NEW: > > >>>>> new text > > >>>>> > > >>>>> You do not need to reply with both an updated XML file and an > > >>>>> explicit list of changes, as either form is sufficient. > > >>>>> > > >>>>> We will ask a stream manager to review and approve any changes > > >>>>> that seem beyond editorial in nature, e.g., addition of new > > >>>>> text, deletion of text, and technical changes. Information > > >>>>> about stream managers can be found in the FAQ. Editorial > > >>>>> changes do not require > > >> approval from a stream manager. > > >>>>> > > >>>>> > > >>>>> Approving for publication > > >>>>> -------------------------- > > >>>>> > > >>>>> To approve your RFC for publication, please reply to this email > > >>>>> stating that you approve this RFC for publication. Please use > > >>>>> ‘REPLY ALL’, as all the parties CCed on this message need to see > > >>>>> your > > >> approval. > > >>>>> > > >>>>> > > >>>>> Files > > >>>>> ----- > > >>>>> > > >>>>> The files are available here: > > >>>>> https://www.rfc-editor.org/authors/rfc9378.xml > > >>>>> https://www.rfc-editor.org/authors/rfc9378.html > > >>>>> https://www.rfc-editor.org/authors/rfc9378.pdf > > >>>>> https://www.rfc-editor.org/authors/rfc9378.txt > > >>>>> > > >>>>> Diff file of the text: > > >>>>> https://www.rfc-editor.org/authors/rfc9378-diff.html > > >>>>> https://www.rfc-editor.org/authors/rfc9378-rfcdiff.html (side > > >>>>> by > > >>>>> side) > > >>>>> > > >>>>> Diff of the XML: > > >>>>> https://www.rfc-editor.org/authors/rfc9378-xmldiff1.html > > >>>>> > > >>>>> The following files are provided to facilitate creation of your > > >>>>> own diff files of the XML. > > >>>>> > > >>>>> Initial XMLv3 created using XMLv2 as input: > > >>>>> https://www.rfc-editor.org/authors/rfc9378.original.v2v3.xml > > >>>>> > > >>>>> XMLv3 file that is a best effort to capture v3-related format > > >>>>> updates > > >>>>> only: > > >>>>> https://www.rfc-editor.org/authors/rfc9378.form.xml > > >>>>> > > >>>>> > > >>>>> Tracking progress > > >>>>> ----------------- > > >>>>> > > >>>>> The details of the AUTH48 status of your document are here: > > >>>>> https://www.rfc-editor.org/auth48/rfc9378 > > >>>>> > > >>>>> Please let us know if you have any questions. > > >>>>> > > >>>>> Thank you for your cooperation, > > >>>>> > > >>>>> RFC Editor > > >>>>> > > >>>>> -------------------------------------- > > >>>>> RFC9378 (draft-ietf-ippm-ioam-deployment-05) > > >>>>> > > >>>>> Title : In-situ OAM Deployment > > >>>>> Author(s) : F. Brockners, Ed., S. Bhandari, Ed., D. Bernier, T. Mizrahi, > Ed. > > >>>>> WG Chair(s) : Marcus Ihlar, Tommy Pauly > > >>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker > > > > > > >
- [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-ippm-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-i… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-i… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-i… Frank Brockners (fbrockne)
- Re: [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-i… Tal Mizrahi
- Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-i… Sarah Tarrant
- Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-i… Frank Brockners (fbrockne)
- Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-i… Sarah Tarrant
- Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-i… Martin Duke
- Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-i… Sarah Tarrant
- Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-i… Frank Brockners (fbrockne)
- Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-i… Shwetha Bhandari
- Re: [auth48] [AD] AUTH48: RFC-to-be 9378 <draft-i… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-i… Sarah Tarrant
- Re: [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-i… Bernier, Daniel
- Re: [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-i… Sarah Tarrant