From florian.kauer@linutronix.de Wed Dec 13 03:06:48 2023 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7E0C14F682; Wed, 13 Dec 2023 03:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=linutronix.de header.b="OXpoyd1Z"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=linutronix.de header.b="lJXcWXt5" 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 3ryk0cmoH4KU; Wed, 13 Dec 2023 03:06:44 -0800 (PST) Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 B20D7C14F602; Wed, 13 Dec 2023 03:06:43 -0800 (PST) Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1702465601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=wVamkRwYPFeLQ5Eu0CNhVz70yD5xkOuU4F69Sh7iz0A=; b=OXpoyd1Z+4Lb5Db3MI0xoJFY+UkEYRJhGuZ8cLbzuYKQ92jQrSD/Npu2MksxtdPMBGNh9u FUJ1OCEPMNQBWibDtCbF4EOtknef1XeC+3B0vZH27qpjXLag7QG5m5ymnE5zDIpBczWbMx IpSUEDjGCNljnrb99hDGgkpn3MW/2boyXG+m72rCzoYdcT/9YaPuQg2hOyfJu9yYhvErJO iMc4C+FxPH/9ydnRIANojPKBhE73XVJh2pkn7Uy6X24FEn7PdfLNmuUt9veAbKRzZ5yiNf kEI52YYsUxaJ4+GdOJz3uS0l1akp3WWlE/hcNe5n2fpVEi7If8FacuFqNadFng== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1702465601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=wVamkRwYPFeLQ5Eu0CNhVz70yD5xkOuU4F69Sh7iz0A=; b=lJXcWXt52Dewha4fmgUp39hLHp6lqS5u4txh+ft/Cmsg9Yx0ykmohG43oLVui8dsciBQ91 uTCcMNpCybYpjCBg== Date: Wed, 13 Dec 2023 12:06:39 +0100 MIME-Version: 1.0 Content-Language: en-US To: "Frank Brockners (fbrockne)" , Greg Mirsky , DetNet WG , mpls , 6man WG , IETF IPPM WG , opsawg , Pascal Thubert , Loa Andersson References: From: Florian Kauer Autocrypt: addr=florian.kauer@linutronix.de; keydata= xsFNBGO+z80BEADOSjQNIrfbQ28vjDMvs/YD/z0WA/iJNaD9JQDXNcUBDV1q+1kwfgg5Cc7f rZvbEeQrO7tJ+pqKLpdKq6QMcUW+aEilXBDZ708/4hEbb4qiRl29CYtFf8kx4qC+Hs8Eo1s3 kkbtg/T4fmQ+DKLBOLdVWB88w6j/aqi66r5j3w9rMCaSp0eg7zG3s/dW3pRwvEsb+Dj7ai2P J1pGgAMKtEJC6jB+rE17wWK1ISUum22u17MKSnsGOAjhWDGiAoG5zx36Qy5+Ig+UwIyYjIvZ lKd8N0K35/wyQaLS9Jva0puYtbyMEQxZAVEHptH1BDd8fMKD/n03GTarXRcsMgvlkZk1ikbq TL9fe2u9iBI861ATZ4VwXs48encOl3gIkqQ/lZbCo8QRj7pOdvOkx/Vn20yz809TTmRxCxL1 kdSbHROfEmUCAQdYSLUUfPYctCIajan/zif/W3HZKJJ3ZTbxdsYonLF9+DSlkFU+BSL147in tDJ83vqqPSuLqgKIdh2E/ac2Hrua0n80ySiTf7qDwfOrB8Z2JNgl1DlYLbLAguZJ4d608yQZ Tidmu22QopA47oQhpathwDpEczpuBBosbytpIG7cNvn98JnEgWAwRk0Ygv9qhUa/Py4AcYG8 3VEkoTZ9VNSP1ObMxcraF+KH5YYkR6Rd2ykmTulh4FqrvyOyMwARAQABzStGbG9yaWFuIEth dWVyIDxmbG9yaWFuLmthdWVyQGxpbnV0cm9uaXguZGU+wsGUBBMBCgA+FiEE8X2LVBM8IilJ PmSgtZdt1lJRlE4FAmO+z80CGwMFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ tZdt1lJRlE41Kw/9EMsgm3D6a4a8J4iKw5UGyDu31LbVW83PKIZ8lALdtzNuT/1Q85IKc7lT +hFtYYLos05tjo0lQ2SCf5qRP7FY/hGnk+1Hqnog9eloG+Eh522iojId2rPL4I9w0XvlN4Mm BleqCvBn3YPVGW0kxJXTwZDRQfReVLeFSKTvXwWYJYrvleF2Cgyom/tcNrugHJfVPOYOe/qN NpiIawhF8Q/9YnGeW0FydhrIB+A4jJvuk36mt6/D/Mqj7kbYp0vGYXmt7lbp/n8luApzNwbZ gJzMa+a8l2+5b+95zaJMcxYSP9M26uS5khTCWDs9PcasFB9IfU0uHAhIPxV6SNVXK1A0R8VY 2gxtprowtbnWBCIRh2xJls6sOUn4EJH0S0/tlTM/wOH2n3wrKqhz+8gQF5hj3f8P5B5UL/05 uhZg3zyeTFhQl2zqaD+a1KI4Dm0vf1SfnCpsvJvimfWoyRgMnSuosN+JC2b9LuR7Leq3g0lC okVY6546ccr7i4YaGKcdQX8/+0tFECNlhKPjR3ycQXToCquzkuMuHW/5ugmcFaebAOZ1nPT8 v/IdeuephUj4Xa8GUHmly/t44k1SH8xh2GHYAav43Yo7an2eJwBhRx+4vJioFK134fFTzBET DelXAoM5z9A21h1ZTEHHxro2DLbmzEmfDf97Hjhvwytupf1fHwbOwU0EY77PzQEQANDDECcC GPzSBAbMY56gUC7pLSy4+2KSRWS4cz3fNb6HHEmdSvhu+oq0zxm3Q04eJO2Mcu5DfTWEng+d u2rxRAGqDu/b/EVC0AbQLuDL2kvnO5LOVR9JPcyrsTGyrfq84QspY/KzTZaWkDbTX2G3yLmz AJs19LyehFC3kfSyQBcsvPR3fb/gcuU+fYhJiAFrHERovnSCA/owKRrY4aBzp7OGJQ2VzjbT g81rWnJY2WJGSzu5QPbU4n/KT+/NrkNQ91/Qsi8BfHmg4R1qdX7vNkMKWACttQKHm38EdwaH cX4hzYXad0GKzX219qeExt83dSiYmzLO8+ErJcCQPMIHViLMlLQVmY3u7QLE2OTHw51BRyhl i3Yjeqwzh5ScIOX3Fdhlb18S2kPZQZ/rRUkrcMUXa/AAyKEGFZWZhpVBTHSn+tum7NlO/koh t4OKO84xkaoa+weYUTqid86nIGOfsgUOZ192MANK/JggQiFJTJ2BMw/p3hxihwC1LUsdXgqD NHewjqJhiTjLxC6ER0LdrTURG4MS2tk5WjRgpAaAbKViXLM/nQ7CVlkyzJsdTbiLflyaHHs2 s18O+jiXDGyQQBP5teBuYFZ3j5EB2O+UVbQMBHoeZJQrtKgxHyyj9K0h7Ln/ItTB3vA9IRKW ogvwdJFhrSZBwoz+KQoz3+jo+PcBABEBAAHCwXwEGAEKACYWIQTxfYtUEzwiKUk+ZKC1l23W UlGUTgUCY77PzQIbDAUJA8JnAAAKCRC1l23WUlGUTq6wD/4zGODDbQIcrF5Z12Cv7CL2Qubb 4PnZDIo4WNVmm7u+lOXciEVd0Z7zZNZBClvCx2AHDJyPE8/ExqX83gdCliA2eaH2qPla1mJk iF6U0rDGGF5O+07yQReCL2CXtGjLsmcvYnwVvB5o70dqI/hGm1EKj1uzKRGZSe6ECencCIQ4 2bY8CMp+H5xoETgCw90FLEryr+3qnL0PEfWXdogP4g+IQ9wSFA3ls4+4xn6+thpWNhVxEv/l gEAES2S7LhgDQUiRLusrVlqPqlpQ51J3hky56x5p5ems42vRUh6ID/0mMgZQd+0BPgJpkovs QoaQAqP2O8xQjKdL+YDibmAPhboO1wSoy0YxxIKElx2UReanVc06ue22v0NRZhQwP9z27wwE Bp9OJFE0PKOM5Sd5AjHRAUoFfMvGSd8i0e3QRQHEcGH1A9geAzY+aw7xk8I2CUryjAiu7Ccd I6tCUxSf29+rP4TKP+akaDnjnpSPwkZKhPjjEjPDs9UCEwW3pKW/DtIMMVBVKNKb5Qnbt02Z Ek1lmEFP3jEuAyLtZ7ESmq+Lae5V2CXQ121fLwAAFfuaDYJ4/y4Dl1yyfvNIIgoUEbcyGqEv KJGED0XKgdRE7uMZ4gnmBjh4IpY6a2sATFuBiulI/lOKp43mwVUGsPxdVfkN/RRbFW7iEx63 ugsSqUGtSA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ippm] [Detnet] IOAM, iOAM, and oOAM abbreviations X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2023 11:06:48 -0000 Hi, so does in-band OAM (RAW architecture) actually mean exactly the same as In-situ OAM (RFC 9197)? If yes, both should be named and abbreviated exactly the same way and since RFC 9197 is already published, it should probably be In-situ OAM (IOAM). (But the question then is what is out-of-band OAM? Out-situ OAM? ;-) ) If no, PLEASE don't use the same abbreviation for slightly different things, even in slightly different contexts. I acknowledge the preference of those working on a very specific topic to keep their daily used terminology as concise as possible, but as someone who tries to get into all those topics to understand the bigger picture or to actually implement something, specific abbreviations are always a hurdle, especially when they have different meanings in slightly different contexts. So I really like inb-OAM and oob-OAM, because you can really "see" the origin in it without repeatedly asking yourself if "i" stands for in-situ, in-band, internet, industrial, intelligent... If you need a whole new section in an RFC just to explain the different uses of I in an abbreviation, you will likely spend more key strokes on that section, than on the additional "nb-"s ;-) Just my two cents. Greetings, Florian On 13.12.23 11:54, Frank Brockners (fbrockne) wrote: >   > > When IPPM started working on IOAM, there was a long discussion on naming – and the conclusion was that “in-band” as not appropriate for OAM information being piggybacked on top of user traffic. This is why the IPPM WG concluded to use “In-situ OAM” – or “IOAM” for short, which is what is used in RFC9197 and all related documents. > > Frank > >   > > *From:*ippm *On Behalf Of *Greg Mirsky > *Sent:* Wednesday, 13 December 2023 04:13 > *To:* DetNet WG ; mpls ; 6man WG ; IETF IPPM WG ; opsawg ; Pascal Thubert ; Loa Andersson > *Subject:* [ippm] IOAM, iOAM, and oOAM abbreviations > >   > > Dear All, > > Loa and I have discussed these abbreviations to help us find a solution that avoids the confusion we found when we came across them. Firstly, what they stand for: > > * IOAM - In-situ OAM (RFC 9197 ) > * iOAM - in-band OAM (RAW architecture ) > * oOAM - out-of-band OAM (RAW architecture ) > > We discussed the issue with Pascal and came to slightly different abbreviations for the last two: > > * inb-OAM > * oob-OAM > > We also discord these abbreviations with the RFC Editor. Resulting from that, RFC Editor agreed to add IOAM to the RFC Editor Abbreviation List . The other two abbreviations cannot be added at this time. If that is needed, we can ask the RFC Editor to add them once the respective RFC is published. > > We are seeking your feedback on the following: > > * Do you see the benefit of introducing two new abbreviations for in-band OAM and out-of-band OAM? > * Which set of abbreviations (iOAM/oOAM vs. inb-OAM/oob-OAM) do you prefer for being used in IETF?  > * Or would you propose another set of abbreviations? > > Regards, > > Loa and Greg > >   > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet